HOLLYWOOD, CALIF.—Shortly before the start of the SMPTE 2015 Annual Technical Conference & Exhibition, TV Technology spoke with Paul Briscoe about his upcoming session “Considerations in Interoperability Testing of the New Sync System.”
TV Technology: Would you explain the driving force in moving away from conventional television plant reference technologies (black burst and tri-level sync) and into the realm of precision time protocol (PTP) system synchronizing?
Paul Briscoe
Paul Briscoe: There are two primary drivers motivating this technology shift. The first and biggest one is the emergence of IP as the next infrastructure plumbing medium. Using an IP-native Standardized PTP method under the hood ensures that we can use it with IP infrastructures that leverage the incredible economies of scale of that industry. The second driver is the SMPTE 2059 Standard suite, which links the network-based PTP timekeeping to all of the media Standards. This means that building systems containing legacy technology and new IP infrastructure can be synchronized in a harmonized and seamless manner. It is of utmost importance that we put in place toolsets like this, which accommodate legacy requirements fully as well as new and future ones in order to enable an evolution rather than force revolution.
TVT: When you speak of the need for “testing,” it would seem that you are referring to the initial creation and set up of the system; is this correct or is there a need for continuous testing to ensure compliance?
Briscoe: Testing in the context of this presentation refers to the initial interoperability testing among early implementers of the technology. The intent of this testing is two-fold. One aspect is to ensure that the Standard actually works as intended and is correctly written, and to test this we have pre-established a set of tests and expected results; it’s also encouraging when independent implementers turn up with implementations that behave the same.
The second intent is to demonstrate and prove that compliant implementations of the Standard will interoperate. A collateral benefit of these two is that they help us prove out the Standard overall. This testing is intended to be conducted one time only (though in multiple sessions), the result being proof that the Standard is correct and achieves interoperability. Thereafter, the Standard can be used to build implementations that only require compliance testing by the builder against the Standard.
TVT: What are the important parameters to evaluate in an ST2059 reference system? Does such evaluation involve human observation and interpretation of results, or is this something that can be done on an automated basis with minimal human involvement?
Briscoe: There are three parametric domains that we’ll be testing. The first is the actual PTP network behavior, and this is based on parameters laid out in the Standard. In addition to verifying that the SMPTE PTP parameters work correctly, testing will “beat it up” with things like traffic scenarios, packet loss, packet delay variation and so on. Note that these tests apply to both master generators and slave devices. The second domain is the legacy signal testing. The Standard provides for generation of many (most) media signals, and this will be confirmed, each against their Standards looking at things like jitter, wander and lock time, and again by interoperability verification.
Finally, a special case of a signal is time code, because it conveys time inside a legacy signal. This is a tough one because precision timekeeping is a complex topic, and in North America and elsewhere, we have non-integer frame rates that are offset from real time, so discontinuities are part of minute-by-minute and daily life. There is an entire suite of tests dedicated to ensure that, when derived from PTP, time code will be the same as that which we use today.
Testing includes looking at compliance with the drop frame rules and discontinuities. This testing is essentially lab testing and is mostly non-automated. Subsequent to the completion of this work, there is no real need for others (outside of developers, and rarely end users) to do this kind of testing.
TVT: You refer to “signal and time-code generation;” could you please elaborate on this, as obviously time code is and has been for several decades a very important element in television post production and other areas; however, due to the fractional frame rates that have been around since 1953 and will likely persist into the future (at least in the U.S.), timecode generation/usage is still something of a “bear” to deal with. Will ST2059 referencing make time-code-dependent operations easier or more difficult? Where does the need for testing arise in connection with time-code generation?
Briscoe: The fractional frame rate issue was indeed the most challenging part of the Standard to figure out. Part of the complexity is that rather than being transmitted as a direct time code value over dedicated wires (LTC) or in the video (VITC/ATC), the time is independently derived from PTP. While this might seem to solve the problem, time coming from time, the snag is that the time code time is off frequency to match the video. Thus, the time values need to track the drop frame rule, which keeps them close to real time.
At the end of the day there is an accumulated error, which is removed by jamming real time into the code. In traditional systems, this is simple — the master is jammed and everyone receives new time code. In a PTP system, the jam is a virtual activity at the receivers, signaled by the master, so not only do the receivers need to do the calculations necessary to figure this out, they all need to act as though they received the new time code at the same time as each other as well as legacy receivers. In addition, a receiver powered up in the middle of the day (between jams) needs to know when the jam occurred in order to calculate where it is in the daily dance of drop frame to know the correct time.
In future, more advanced time labels can offer the opportunity of carrying better information than ST12 time code, for example the PTP precision timestamp, arbitrary frame count, and so on, and these concepts can be based on the foundational work of the ST2059 Standard.
TVT: This is probably a little off-track, but as television production/broadcasting entities are likely to be operating with a mix of state-of-the art and legacy equipment in the near future and for some time thereafter, what are the implications of mixing the two rather disparate referencing requirements of such a hybrid system?
Briscoe: When we started the work that became ST2059, IP media transport was obvious, but not in sight. However, we realized that not only was an IP solution for synchronization required, it had to enable the construction of all legacy signals used today. This means that IP-based slave generators and equipment could derive all of the references they need today, and that the appropriate reference foundation (PTP) was living on the network for the next step towards IP, whatever that might be. Upon examination, the requirements for synchronization are not too disparate after all.
Clearly we were not going to change video Standards in the move to IP; it’s really about plumbing, so the same algorithms and math used for legacy signal generation are equally appropriate in IP transport, and the nature of the Standard is such that any reasonably conceivable video or audio format that could come along could be accommodated — in legacy or IP plumbing.
Briscoe began his career in the broadcasting industry in 1980 at the CBC in Toronto. He jumped ship from CBC in 1994 to join Leitch Technology (subsequently Harris Broadcast, now Imagine Communications). Working up to the position of principal engineer, he left Harris Broadcast in November, 2013, and now provides system, technology, design and standards consultation to the ever-evolving media industry. He has several patents granted and in process, is a member of SMTPE and IEEE, and is an active participant on numerous SMPTE standards committees.
