WESTFORD, Mass.—Artel Video Systems has announced that Television City Studios (TVCS) in Los Angeles has selected Artel Quarra PTP 10 Gbps Ethernet switches as the basis for the new Precision Timing Protocol (PTP) distribution network at the production facility. 

Television City Studios has been home to legendary shows such as "The Carol Burnett Show" and "All in the Family" and today broadcasts "The Price Is Right," "The Late Late Show with James Corden," "American Idol," among others. 

The facility has begun migrating to media-over-IP, and the recent deployment of various systems operating in a SMPTE ST 2110 environment meant engineers had to build a reliable PTP distribution network from scratch.

"We chose Artel's Quarra 10G for several reasons," said Jerzy Gorczyca, vice president of TVCS engineering. "For one thing, Artel gave us loaner units so we could evaluate the device before moving forward with a purchase. During that time, we found that the accuracy was spot-on, and the web browser interface made for easy configuration. Also, Artel's engineers were readily available with complementary technical support whenever we needed it. Another determining factor was that Artel will work with us as our needs continue to evolve."

In the Television City workflow, two Quarra 10G switches serve as boundary clocks in the PTP distribution network. The boundary clocks support equipment in two studios in a redundant fashion (blue and red networks) and are referenced by Evertz 5700MSC-IP grand master clocks. The Quarra switches take PTP messages from the grand master clocks and pass them to other timing distribution switches located in different studios.

Quarra 10G PTP switches can operate in either boundary clock or transparent clock mode. They provide accurate holdover when the PTP grand master is lost, the fastest boot time in the industry (less than 30 seconds), and nanosecond timing accuracy, thanks to a design that uses accurate temperature and voltage-controlled, high-precision crystal oscillators, the companies reported. 

With the Quarra switches in the PTP workflow, signals are synchronized within nanoseconds so that TVCS can avoid broadcast interruptions, unwanted noise, lip sync misalignment, and audio latency that arise from errors in timing.

"Television City was the first studio in the world built especially for television, and it has evolved a lot since it first opened in 1952. Artel is pleased to be a part of that evolution," said Rafael Fonseca, vice president of product management at Artel. "With the Quarra's ease of use, accuracy, and flexibility, coupled with Artel's commitment to customer support, Television City can be assured of precision timing that gives viewers the best possible experience."

Additional information about Artel products is available at www.artel.com.

Our industry has been talking about remote production for a while, and for good reason. The conventional live production model, in which a team and equipment are sent to the venue, can be costly in terms of both time and money. Travel is expensive not only because of transportation and lodging, but also because the human and technical resources are tied up all that time and unavailable for any other production. As a result, you’re limited in the frequency and number of events you can produce.

Remote production solves many of these issues. While you still send a team to the venue, you can keep specialized staff and equipment in a central location, available to support multiple events throughout the day. With the emergence of COVID-19, and the need to shift to distancing and remote work scenarios, the appeal of remote production has become even greater.

IP is a key enabler of remote production applications, as it supports transport of both audio and video, as well as the data, communications and control signals critical in the production environment. Oftentimes, the challenge lies in connecting two remote sites, each with its own media-over-IP infrastructure but lacking the IP switching and Precision Time Protocol (PTP) implementation essential to preserving timing and synchronization across both sites.

PTP specifies a methodology for synchronizing devices to a single shared clock across packet-based networks (using SMPTE ST 2110 and AES67), including Ethernet switches and IP routers. Creating a common time base for multiple AV sources, PTP enables synchronization of device clocks to within nanoseconds, even across a large network.

Because PTP is sensitive to delay, the best way to maintain synchronization across the transport network connecting two sites is to deploy PTP generators at each site. (Some facilities do continue to use SDI transport to sidestep this requirement, using IP solely for control, management and monitoring.)

The resulting topology would typically include a PTP generator, PTP-aware switching and IP transport at each site. The signal flow therefore would look like this: PTP Generator 1 — PTP-aware switching — IP transport — fiber — IP transport — PTP-aware switching — PTP Generator 2.

Connected to the PTP generators, the PTP Ethernet switches leverage internal timing circuitry to minimize time drift and maintain highly accurate timing synchronization. In the case of the PTP aware switches, integrated support for QoS and traffic management help to ensure signal reliability and integrity.

In this example, each PTP-aware switch could connect to an SDI-over-IP multifunction gateway, likely autosensing to support 3G, HD and SD, with an integrated non-blocking Layer 2/3 switch. Ideally the gateway attaches to the IP network without the need for external network elements.

The signal flow in this model is basic, and the components install simply. Even more important, synchronization is maintained across the two sites, ensuring proper handling of audio and video throughout live production. With this problem solved, production teams can focus their time and energy on other aspects of creating a great show using a collaborative remote workflow. The entire organization—and viewers too—benefit from this at-home production model, which increases not just efficiency, but also the expertise and technical resources that can be dedicated to multiple live broadcast events.

Rafael Fonseca is vice president of product management for Artel. 

LOS ANGELES—One oft-touted advantage of transitioning from SDI baseband video to an IP equivalent is the ability to use common off-the-shelf (COTS) computer hardware to replace specialty video equipment.

The idea is that the economies of scale the computer industry brings to the table are so far superior to anything the M&E industry can muster, which should make it easier for broadcasters and others to adopt IP-based workflows.

However, a presentation at the SMPTE 2018 Annual Technical Conference and Exhibition by Jean Lapierre, senior director of software engineering at Matrox Graphics, sheds a somewhat different light on the issue. While his “Bridging The Gap Between Software and SMPTE ST 2110” presentation did not address the cost issue, it did throw into question the notion of “common” in “common off-the-shelf” computer hardware for M&E applications.

“We think that ST 2110 with full implementation of [ST] 2059 is very difficult using a generic network card and some software,” he said. “It’s much easier if we are leveraging some hardware acceleration on the network card. And we think that the way to do that is to use an FPGA-based network card that actually understands the full ST 2110 implementation.”

PACKET SPACING

Lapierre offered several examples of situations in which a conventional network interface card (NIC) and use of a computer’s CPU would not be up to task.

For instance, traffic shaping is “actually quite tricky to do in software,” he said. Lapierre explained that simply using software to packetize a frame of video and send it as fast as possible on the network is not a realistic solution.

He pointed to an example of 1080p 60 video at a little bit less than 3Gb/s being sent over a 10Gig network.

Sending a frame from a hypothetical source A as fast as possible will take about a third of the memory in a receiver’s buffer. However, if two more sources are added and all three burst their packets onto the network, the network switch will not be able to send all of the packets at the same time. This will require buffering, said Lapierre.

With just three sources, this approach is acceptable. “Where we get into trouble is when you try to move that to scale,” he said.

A far bigger buffer will be needed on the switch; however, it still may be inadequate and have to drop packets, which is undesirable, he explained.

SMPTE ST 2110 addresses this situation through packet spacing, which is “a nice way of spreading packets over time,” which creates holes for other packets to fill as they traverse a network, he said.

In the same example, the same amount of data is sent on the network, but spread out over time, allowing the receiver to build up the frame. With packet spacing, if two more sources are introduced, the switch only has to buffer a smaller part of the second and third source, he said.

However, doing so in software is tricky, said Lapierre. One strategy is to build time loops to build in the needed delay, but that wastes CPU cycles that could be used on an important task.

Additionally, the computer’s operating system may have an essential task to perform, putting the time loop to sleep momentarily to accomplish the task, thereby unexpectedly extending the duration of the loop.

“We think it is better to leave that job to a network card that can do the packet spacing for you.”

PTP-AWARE NETWORK CARD

Precision Time Protocol (PTP), which keeps audio and video packet flows from multiple streams in step in time, is also a challenge in a software implementation.

In this example, PTP would require a network stack, consisting of a grand master clock, a conventional NIC, an operating system and the software implementation, he said.

“Well, my piece of software uses that stack to talk to the grand master to find out what time it is, and by time the message comes back I have to try to figure out how long it took for this message to get there and how long it took to get back,” he explained.

The problem is it can take a variable amount of time to go through the stack, he added.

“We can improve our situation by using a network card that understands our situation,” said Lapierre. However, the precision of PTP that is possible in software is inadequate and “can wreak havoc,” he said.

“What we think is better is if the network card, which is PTP-aware, is the one responsible for doing the time stamping—and why not [also] doing the packet spacing,” he said.

By adding a network interface card to a system with on-board ST 2110 and ST 2059 support, vendors can spend their development time improving their own Software solutions, not dealing with these network interfacing issues, he explained.

“Also, if we look at all the CPU processing we are talking about we will be wasting CPU cycles doing timing loops and things of that nature. To me, if we do that, it sounds like we are doing less with more and not more with less,” he concluded.

Click on the Image to Enlarge

We are at the beginning of a long-term transition to IT-based infrastructure and those involved in the production and facility side of video have little experience with the new technology, but conversely are extremely experienced using SDI and all the issues associated with its use. This, coupled with a huge investment in existing technology, makes it likely that a hybrid SDI/IP infrastructure will be in place for some years.

As such, production facilities will require equipment that can operate seamlessly and reliably in a hybrid environment. And because a broadcast live production network is entirely reliant on a stable reference and any timing and synchronization devices “must work.”

In general, when referring to video over IP in the context of any video production workflow, the focus is on the distribution of either baseband or lightly compressed video over Real Time Protocol or RTP. In a live production environment, it is critical to consider synchronization and timing. The asynchronous nature of IP allows many different traffic types without synchronization concerns, but this presents a challenge in a production environment where synchronization is critical for frame-accurate switching and synchronous video processing.

ACHIEVING GENLOCK

The necessary “genlock” for both IP and Ethernet networks is achieved using IEEE 1588-2008, or PTP (Precision Time Protocol) v2. This is also the basis of a recently introduced SMPTE PTP standard, specifically intended for the timing and synchronization of video transmitted over RTP networks. Although PTP provides a mechanism to synchronize the real time clocks of devices on an Ethernet-based network, it does not make the network itself synchronous.

Deriving the correct time in a PTP network.

The adoption of video over IP and the use of PTP means a network time server is required to provide PTP genlock functionality equivalent to that delivered by a sync pulse generator (SPG) in SDI networks.

Any grouping of synchronized clocks is referred to as a PTP domain. The PTP network time server is called a PTP grandmaster, with a device that derives its timing synchronization from PTP referred to as a PTP slave. A master provides the time in a given PTP domain and a slave is a device that synchronizes to a master. A grandmaster is the ultimate source of clock synchronization.

For broadcast applications, PTP grandmasters are usually synchronized to GPS, GLONASS or both, in order to derive accurate timecode using the 1970 Epoch. To enable legacy equipment support, hybrid PTP grandmaster and SDI SPG equipment is now available on that market that can phase baseband timing outputs relative to either the 1970 or 1958 Epoch dates.

OVERCOMING NETWORK DELAY

As defined, PTP is a method for distributing time over a network, with a single grandmaster providing the source of time, to synchronize one or more slaves. In an ideal world the network delay could be programmed into each slave which could then be offset to the time in the received packet to derive the correct time. Such symmetry can only be relied upon in point-to-point IP links. Unfortunately, the delay in switched/routed IP networks is both variable and asymmetric, so the slave devices must periodically send delay request messages to the grandmaster. The grandmaster accurately time stamps these messages on receipt and the time of receipt is sent back to the slave in a delay response message.

As shown in Fig. 1, the slave is now able to calculate the difference between its own clock and that of the grandmaster using the master-to-slave sync packet delay (T2-T1) and slave-to-master delay request packet-delay (T4-T3). The offset (slave time – master time) = [(T2-T1)-(T4-T3)]/2 and the one way delay = [(T2-T1)+(T4-T3)]/2. For the slave time to be now correct, the propagation delay in both directions must be equal.

If the propagation delay in both directions is in fact different, then the slave is offset to “correct” for this by adjusting its clock to a value of half the asymmetry. The clock’s control loop adjusts the slave time to make the master-to-slave and slave-to-master propagation delays appear to be equal. That is, the control loop adjusts the slave time such that T2-T1 = T4-T3.

PTP CLOCK TYPES

It is vital that switches and routers in any IP video network that relies upon PTP for synchronization are “PTP aware” and able to account for their own queuing delay to ensure downstream timing accuracy. This can be achieved in one of two ways. The first is by the switch acting as a transparent clock which hardware time stamps sync and delay request messages on arrival and departure and adds the difference to a correction field in the message.

The second way for a switch or router to account for its own queuing delay is to act as a boundary clock, which receives time from a master on one slave port and provides one or more master (not grandmaster) ports to downstream slaves in a PTP domain and in doing so, removes the effect of its own queue.

PLANNING AHEAD

For hybrid IP/SDI broadcast applications, it is essential that the PTP grandmaster provides support for application specific video and audio PTP profiles, such as SMPTE 2059 and AES67, as well traditional SPG features including black burst, tri-level and SDI out. All the above protocols must be referenced to the same GPS clock, or such a hybrid IP/SDI network would be inoperable.

Paul Robinson is a 29-year veteran of the test and measurement industry. In his current role, Paul is CTO for Tektronix’ Video Test Business focused on developing test, measurement and monitoring solutions aimed at the enabling the deployment of digital television and helping to bring IP video products and services to market.

Paul joined Tektronix in 1986 as an Applications Engineer and has held a wide variety of senior roles within the company both in Europe and the U.S. Paul started his professional career in the broadcast industry and prior to joining Tektronix, he worked for the BBC as a senior systems engineer. Paul has a B.Sc. in Applied Physics and a DUniv from Buckinghamshire New University.