SMPTE Standards Webcast Series SMPTE Professional Development Academy Enabling Global Education The SMPTE ST 2059 Network-Delivered Reference Standard Paul Briscoe, Consultant Toronto, Canada SMPTE Standards Update Webcasts Professional Development Academy Enabling Global Education Series of monthly 1-hour online, interactive webcasts covering select SMPTE standards Free to everyone Sessions are recorded for on-demand viewing convenience (YouTube) 2016 Powered by SMPTE Professional Development Academy Enabling Global Education www.smpte.org 1
Your Host Joel E. Welch Director of Education SMPTE Professional Development Academy Enabling Global Education Today s Guest Speakers Paul Briscoe Consultant Professional Development Academy Enabling Global Education 4 2
Views and opinions expressed during this SMPTE Webcast are those of the presenter(s) and do not necessarily reflect those of SMPTE or SMPTE Members. This webcast is presented for informational purposes only. Any reference to specific products or services do not represent promotion, recommendation, or endorsement by SMPTE or SMPTE Members Let s talk about synchronization Live television facilities operate in a synchronous manner All signals are frequency locked to a reference All signals are phase adjusted ( timed ) according to use Started with the first TV transmission Scanning beam on camera was tracked by receiver Production had to keep the beam on track when switching This requirement has followed us to the digital age of SDI..and got more complex Live IP systems have the same issues and more. So we re stuck with it. Can we make it any better? 3
Synchronization analogy Synchronization analogy Studio A Studio B Edit 1 Edit 2 Graphics OB Truck Master Generator Feeds MCR 4
Synchronization analogy Studio B Edit 1 Edit 2 Graphics Studio A OB Truck Master Generators Black, DARS, Timecode Feeds MCR Old-school reference signals Legacy reference signals we know and love BlackBurst, TLS, DARS, Time Code Generate them in a central place (Master (redundant)) Distribute them to all equipment that needs them (Slaves) Used to establish output timing, input windows, time of day Allows building synchronous facilities Can lock master(s) to GPS (GNSS, etc.) (more) accurate frequency reference Time of day for timecode 5
GPS Centralized Equipment Multiple Distribution Trees Master 1 Master 2 Autochangeover BlackBurst DARS Timecode Masters provide redundancy Autochangeover monitors signal health Without external reference, they lock together With external reference, they lock to that Facility Equipment BlackBurst DARS Slave Timecode Problem? What problem? Multiple signals = multiple distributions CAPEX Different distribution hardware and (maybe) cabling OPEX Physical equipment maintenance / single points of failure Inflexible have to pull cables to evolve Break in a path in the tree causes downstream disruption(s) Analog signals (old analog signals!) Technology horizon - EOL 6
GPS Centralized Equipment Multiple Distribution Trees Master 1 Master 2 Autochangeover BlackBurst DARS Timecode X X Loss of a path in the tree results in further downstream reference loss All slaves beyond go freerunning Loss of one signal may be worse than loss of all X X X Facility Equipment BlackBurst DARS Slave Timecode Synchronization analogy Studio B Studio A 4/4 4/4 Edit 1 4/4 Edit 2 4/4 Graphics 4/4 4/4 4/4 9/8 OB Truck Master Generators Black, DARS, Timecode Feeds MCR 7
Distributing fundamental signals What we distribute are media signals posing as reference signals BlackBurst (or TLS) video with no picture DARS audio with no sound Timecode Good ol ST12 (12M to some) longitudinal timecode Why? History. Easy to use in slave equipment natural frequencies (for media) Same interfaces and systemization technologies as media signals Made sense when life was simple. What are we actually distributing? Two fundamental things: Frequency (timebase), which ensures: Signals are locked (stationary in time) wrt one another Frequency of signal is correct (per SMPTE, etc. STDs) Phase ( timing or alignment ), which ensures: Signals are in a deterministic time relationship timed - made coincident (-ish) at points of use Acid test for a system: Main breaker. Everything comes up the same each time. 8
What are we synchronizing? Video sources feeding a production switch / mix / key environment Cameras, feeds, graphics, CG, replay / slomo, servers. Facility resources feeding each other and elsewhere Studios, MCR Audio sources and facilities Router switchpoint timing Automation systems (timecode) What part of the signal do we use? Frequency (timebase) Derived from interface signal edges H (and SC) in video Edges in DARS and Timecode Phase ( timing or alignment ) Largest periodic element of signal ( alignment event ) Vertical in video X or Z preamble in DARS Bit 0 in timecode 9
Meanwhile Things are changing quickly underfoot Analog going away fast no more critical timing performance Technologies are changing really fast Product implementation technologies HW > SW Broadcaster systemization technologies digital > network Distribution technologies many > network Consumption technologies - network Workflows are changing - network IT has arrived. Is there a better way? Nice to have: meets legacy performance requirements one distribution infrastructure, not many one method to carry all references, not many a means of providing redundancy in the distribution something that would directly support new / future standards something that can be externally / globally referenced as close to plug and play as today something that can run over a network 10
A new kind of reference signal IEEE1588 Precision Time Protocol (PTP) Delivers precision time to slave devices over network Runs on IP (and Layer 2) networks Provides for a master ( Grandmaster ) and slave devices Offers master and distribution redundancy Offers external (GPS, etc.) lock to frequency and time Can coexist happily with other network traffic Network switches can participate to improve performance So what? Where s the frequency and phase? What does PTP do? Transfers precision time to many slave devices over a network PTP transfers frequency via running time: 1 GHz virtual clock (timebase) (typically a submultiple) PTP transfers phase via running time: A count value since the time the counter was zero ( Epoch ) High span (~136 years) / high granularity (1 ns) When locked to an external authoritative source, multiple independent masters will have same time and frequency. Global locking possible via GNSS (e.g. GPS) 11
Who uses PTP? Who uses PTP? 12
Time-locked loop theory Algorithm for a human time-locked-loop You have a running pendulum clock Tune in radio time signal at the tone, the time is - set your clock Wait a day (or longer if clock keeps OK time) Tune in radio time signal at the tone, the time is - set your clock, note the error Adjust your pendulum slightly according to magnitude and direction of error GOTO Wait a day. Eventually your clock will maintain correct time (phase) Your pendulum period is accurate (frequency) PTP time counter runs in the master Clocked by a very good timebase Time can be arbitrary (start from zero at powerup) Time can be set locally to approximately the right time (manual) Time and frequency can be authoritative (from GNSS) Master Timebase Oscillator Timebase Master Running Time Count 1588 PHY PTP protocol takes care of network latency Slaves keep a running PTP time count with local timebase Master sends periodic time values to the slaves (1 second) If error is large (say startup), time is jammed Slave looks at time error and adjusts timebase Once locked, master and slave have same frequency and time counts 1588 PHY Incoming Time Count Value 64-bit Comparator Local Running Time Count Slave Running Time Count Network Time Error Time Correction Timebase Local Timebase Oscillator Timebase 13
PTP Range and Granularity 1 Year 1 Month 1 Day 1 Hour 1 Minute 1 Second 1 Millisecond 1 Microsecond 1 Nanosecond Composite Video SDI Video 12M Timecode Calendar AES Audio NTP IEEE1588 GPS Native Time Counter Whole Seconds - 32 bits (~136 years) Nanoseconds 32 bits (1 ns) LSB 1 Hz (PPS) PTP vs. you 1 Year 1 Month 1 Day 1 Hour 1 Minute 1 Second 1 Millisecond 1 Microsecond 1 Nanosecond Composite Video SDI Video 12M Timecode Calendar AES Audio NTP IEEE1588 GPS Native Time Counter Whole Seconds - 32 bits (~136 years) Nanoseconds 32 bits (1 ns) LSB 1 Hz (PPS) 14
PTP on the network Transmits very small packets Can be all of either or a mix of unicast and multicast messaging Reserved addresses Specific network domains Very robust in the presence of traffic IP switches can provide PTP-specific services to improve performance Boundary Clock switches provide unique master on each port Transparent Clock switches process timestamps PTP high accuracy 15
PTP-specific switch types PTP delay measurement 16
So what? We need: Special SMPTE frequencies, not 1 GHz submultiples Specific phase information related to our signals (events) A way to establish deterministic phase relationships Timecode! Getting the funny frequencies Media frequencies are unusual PTP is based on integer frequency Today, cross-synthesis is trivial FPGA-based logic COTS components Source oscillator performance is transferred We do this all the time today inside equipment. Not a big deal. 17
Phase as events Phase is conveyed in legacy signals as alignment events Vertical Event Black Burst V Sync Separator H Logic TCXO V Reset Signal Generator Clock SDI Phase-locked loop H V Events used to reset signal generator SMPTE Frequency Combined with frequency, this is how we lock signals Phase via PTP PTP knows nothing about our requirements it s just time Consider a video signal and a PTP counter For each event, there will be a corresponding PTP time value Next event can be calculated from current event Local Running Time Count Live Running Time Vertical Event Calculate Next Event Compare Equal V Reset Signal Generator Clock 18
Phase anchoring in PTP We need to have an anchor so all slaves are eventsynchronous PTP defines 1970.01.01 00:00:00 as the Epoch Count value was 00000000000000000000000000000000000000000000000000000000 We (SMPTE) define that all signals had their events at the epoch Knowing this, slaves can calculate future events Because events occurred at a known time (epoch), all slaves calculate the same event times. This concept is central to the ST-2059 standard. Locking to time Cross-synthesis of required media frequency Calculation of next event based on epoch Same signal generation bits as legacy gear Local Running Time Count Live Running Time Vertical Event Calculate Next Event Compare Equal V Reset Local Timebase Oscillator 10 MHz Logic TCXO Cross-synthesis Signal Generator Clock H V SMPTE Frequency 19
Does it actually work? Very early tests done with PTP locking a video generator Master generated one signal Two slaves generated two more signals So what about the network? IP networks profuse media systems today Touch most equipment already Non-time-sensitive networks: Configuration and software upgrade Monitoring and Control Time-sensitive networks: Live media transport PTP can live on any / all networks 20
The new opportunity Studio A Edit 1 Edit 2 Studio B IP Network Graphics OB Truck Master Generator Feeds MCR GPS Centralized Equipment Network Fabric (cloud of switches) Grandmaster 1 Grandmaster 2 Autochangeover PTP PT Facility Equipment PTP Slave Masters provide native redundancy (2+) Autochangeover is virtual between masters (PTP BMCA) With external reference, they lock to that, one drives the network Without external reference, one becomes master, other(s) lock to it. With failure of master, another picks up the role 21
The greenfield problem Most people will evolve to network equipment and infrastructure s How to deploy PTP references with legacy systems? Both systems need to have same timebase Both systems need to provide the same signal alignment Facilities / equipment can pick and choose which to use User can evolve from old to new at their will Will require a new kind of master generator scheme GrandMaster + legacy SPG master) GPS Centralized Equipment Network Fabric (cloud of switches) Grandmaster 1 PTP Facility Equipment PTP Slave Grandmaster 2 PTP PTP Slave1 Legacy Master 1 PTP Slave2 Legacy Master 2 Autochangeover BlackBurst DARS Timecode Legacy Master contains PTP slave functionality Legacy signals generated same as any slave Distributed via tree structure as before 22
GPS Centralized Equipment Network Fabric (cloud of switches) Grandmaster 1 PTP Facility Equipment PTP Slave Grandmaster 2 PTP PTP Slave1 Facility Equipment Legacy Master 1 PTP Slave2 Legacy Master 2 Autochangeover BlackBurst DARS Timecode BlackBurst DARS Timecode Legacy Slave Equipment with a choice Black Burst V Sync Separator H Logic TCXO Phase-locked loop V Reset Signal Generator Clock SDI Local Running Time Count Live Running Time H V PTP Slave Calculate Next Event Compare Equal Local Timebase Oscillator 10 MHz Logic TCXO Cross-synthesis 23
What about live IP? Live IP uses PTP as its native timing infrastructure Live media and PTP live on same network Live media transport is by RTP protocol RTP uses timestamps for payload synchronization Network senders use PTP to create media timestamps Network receivers use timestamps to align media streams - also use PTP for internal and legacy output timing PTP used for timecode generation PTP can be used for locking non-ip media equipment RTP Timestamp 24
SMPTE ST2059 SMPTE Standard suite for network-delivered references 2059-1 Epoch and Signal Generation Alignment points for interface signals (that exist today) Formulae for direct calculation of signals from PTP time Formulae and algorithms for deterministically calculating ST12 time-address and ST309 date 2059-2 SMPTE PTP Profile Specific PTP rules required by SMPTE application SMPTE-specific helper metadata Network and SMPTE parameters ST 2059-1 Scope This Standard defines: A point in time, the SMPTE Epoch, which is used for alignment of all signals referenced in this Standard; The alignment of these signals to the SMPTE Epoch; Formulae which specify the ongoing alignment of these signals to SMPTE ST 2059-2 Profile IEEE 1588-2008 PTP time; Formulae which specify the calculation of SMPTE ST 12-1 Time-Address values and SMPTE ST 309 date values from SMPTE Profile IEEE 1588-2008 PTP data. 25
ST 2059-2 Scope and Introduction This standard specifies a Precision Time Protocol profile specifically for the synchronization of audio/video equipment in a professional broadcast environment. The profile is based on IEEE Std 1588-2008 and includes a self-contained description of parameters, their default values, and permitted ranges This profile is designed with the following purposes in mind: To permit a slave to be synchronized within 5 seconds of its connection to the operational PTP network. While there are many factors that will in practice influence the synchronization time, the default values of configurable attributes have been chosen to help achieve this target. Having achieved initial synchronization, to maintain network-based time accuracy between any two slave devices with respect to the master reference within 1 microsecond. To convey Synchronization Metadata (SM) required for synchronization and time labeling of audio/video signals. The SMPTE Epoch Specific origin Epoch for SMPTE 2059 use The SMPTE Epoch shall be January 1st, 1970 00:00:00 TAI, which is the same as the PTP Epoch specified in IEEE Std 1588-2008. Periodic signals in scope of this standard shall have a defined temporal reference point and shall be aligned such that the reference point occurred at the SMPTE Epoch and the signal subsequently maintained its specified frequency. 26
Signal Generation ST 2059-1 specifies the alignment of all common media signals and formats to the Epoch including AES-3 and timecode. Tables convey specific alignment point definitions Formulae convert PTP time value into specific media elements lines, pixels, bits, edges, blocks, samples SMPTE ST2059 27
SMPTE ST2059-1 formulae ST 2059-2 Profile elements A PTP Profile contains application-specific constraints on PTP operation Which of the best master clock algorithm options is to be implemented. Which of the configuration management options is to be implemented. Which of the path delay mechanisms, delay request-response or peer delay is to be implemented. The range and default values of all PTP configurable attributes and data set members. The transport mechanisms required, permitted, or prohibited. The node types required, permitted, or prohibited. The options required, permitted, or prohibited. 28
Synchronization Metadata Helper data for: Generation of date and local time of day Generation of timecode Dropframe is not straightforward daily jam ST2059 makes this better specifies jam time Slaves can figure out what the right timecode is Un-obvious items System primary frame rate Master locking status Timecode Flags Timecode Metadata 29
Timecode in a nutshell 30
Timecode in a nutshell 31
Back to the big picture Which will come first, chicken or egg? Multiple island evolution scenarios available Which kind of island? Which kind of reference? Dual-reference equipment when and for how long? Will it really play nicely on media networks? Will users trust everything on one interface? How long is the ramp? So many questions. First Interop tests Fox NE&O 32
Tests conducted at interop Transport Mechanism Multicast Unicast Mixed Mode BMCA Clock Identity Clock Accuracy Clock Class Priority 1 & 2 Master TLV Lengthfield OrganiztionID OrganizationSubType DefaultSystemFrameRate MasterLockingStatus TimeAddressFlags DaylightSaving Slave TLV Cold Start,25Hz Daily Jam,25Hz Daily Jam,25Hz,ST to DST 2059-1 Output phasing PAL NTSC Network Impairment Delay Jitter Packet Loss Conclusions from first interop ST2059-1/2 fundamentally works as intended Based on the testing that was performed, the standards need only minor clarifications. ST2059 Performance goals for Lock Time and Accuracy are achievable. Tested all of the areas that we planned to test during this interop Future interops expand the areas of testing especially the time code math verification. Highlighted that EGs need to be published EGs help to provide the background context. Identified some clarifications that need to be made in ST2059-1/2 Communication Mode is one area of the standard that would benefit from clarification. Helped to improve vendors products 33
SMPTE Activity 2059 WG is developing EG documents 2059 Interop group is conducting ongoing interoperability tests collaborating with AES to harmonize PTP Profiles Documents are at the one-year review point small clarifications resulting from interop will be made SMPTE SVIP (ST2110) group using 2059 for IP Standard Demos planned for SMPTE Conference and IBC In summary Will work happily alongside legacy systems Will enable new workflows Higher confidence system building Reduced CAPEX Reduced OPEX Can be evolutionary or revolutionary as appropriate Can support any foreseeable future standard / format Reference distribution coming soon to a network near you! 34
Special Thanks The SMPTE / EBU TFTS Team The SMPTE ST 2059 Team Special shout out to those who did the full tour! Peter Symes Leigh Whitcomb Michel Poulin Richard Kupnicki Thank-you! ST2059. Paul Briscoe, Consultant Toronto, Canada 35
Q&A Verbal Questions Encouraged! Paul Briscoe Consultant Professional Development Academy Enabling Global Education Joel E. Welch 36