Timestamps in ST 2110: What They Mean and How to Measure Them

Presenters : Kieran Kunhya - Open Broadcast Systems

Year : 2022

dlp_document_download : Timestamps in ST 2110 and what they mean and how to measure them Kieran Kunhya – kierank@obe.tv Company Introduction Company specialising in software-based encoders and decoders for Sport, News and Channel contribution (B2B) Based in Central London Build everything in house Hardware, firmware, software Not to be confused with: Easy: "How to Explain ST 2110 to a six-year-old" – me, NAB 2022 … … … Medium: This presentation … … Difficult: PTP presentations ( Kernen et al), ST 2110-21/EBU LIST ( Vermost et al) Presentation difficulty level Why do we need timestamps? PTP (very very abridged) RTP timestamp calculation Timestamps vs packet arrival times Measurements How a receiver should use timestamps Where/Why things go wrong What am I going to talk about? In 2110 video and audio are sent as different flows Receivers subscribe to the flows they need to. Audio receiver doesn’t need to receive high bandwidth video Raw video and audio sent on network – From various sources and points in time In order to synchronise , timestamps are used by the receiver to match audio and video Correspond to a given instant of capture All packets of a video frame/field have same timestamp Why do we need timestamps? PTP (very very abridged) Split the audio and video up into thousands of little packets Imagine all television signals start at the same time, Each video frame/field last a number of clock ticks Calculate how many pictures there would have been by now and on which clock tick the next picture will begin 1 st January 1970 (PTP epoch) 52 years later… Now PTP Alignment Point RTP timestamp calculation Timestamp is in the RTP header of each packet using PTP clock 32-bit value, 90kHz clock for video, 48kHz for audio Video timestamp wraps round after ~13 hours, audio timestamp wraps after ~25 hours. 59.94 frame/field rates not divisible by 90kHz Worked Example: Midnight (TAI) 1st June, 2022 at 1080i25: T = 19144 [days] * 86400 [seconds in a day] * 90000 [clock] floor( T / 25 [frames per second] ) * 25 [frames per second] 148863744000000 (PTP timestamp 90kHz) 148863744000000 mod 2^32 = 177520640 = RTP Timestamp = PTP alignment time One Frame or Field Alignment point 1 Alignment point 2 Timestamps vs packet arrival times But the timestamp in the header isn’t the same as the packet arrival time Most facilities use gapped mode to account for historical blanking data and first packet arrives ~700us after beginning of the frame (PTP alignment point) Some scopes don’t make it obvious what time they are referring to. Sometimes hidden in a different menu Will talk later how this can go wrong Understand what you are measuring! Timestamps vs packet arrival times Left: Packet arrival time relative to PTP alignment point Right: RTP timestamp relative to PTP alignment point Either could be wrong! Timestamps vs packet arrival times Similarly need to check both "Video Timing Meters" – packet arrival and "RTP offset Meters" Note: may not have this screen on Phabrix , it requires PHQXO-IP-MEAS Measurements Real senders in our lab (no GPS in our lab so it’s still 1970!): 1970-02-25 05:00:37+0000: First Packet arrived 0.758 ms after ideal , RTP-PTP offset 0.000us (0 rtp ) – Packet arrival GOOD, RTP Timestamp GOOD 1970-02-25 05:01:27+0000: First Packet arrived 0.736 ms after ideal , RTP-PTP offset 11.111us (1 rtp ) – Packet arrival GOOD, RTP Timestamp OK 1970-02-25 05:02:10+0000: First Packet arrived 0.791 ms after ideal , RTP-PTP offset -6655.556us (-599 rtp ) – Packet arrival GOOD, RTP Timestamp BAD Needs continual measurement in real facilities as sometimes jumps happen randomly (!) Similar measurements for audio. How a receiver should use timestamps Receive a timestamp, count how many RTP wraparounds there from PTP Epoch (1 st Jan 1970) to current PTP time. Then can realign received RTP timestamp with current PTP time and have absolute timestamp. Straightforward with modulo arithmetic, though problematic if timestamps are too far in the future or the past Synchronise video and audio and proceed with downstream processing Some receivers not doing this as bad streams work fine into them. Can also send artificial streams with bad timestamps and decode process works, so devices not using timestamps. Where/why things go wrong? Non PTP locked SDI source routed into encapsulator (and encapsulator lacks a frame sync) Symptom: Packet arrival times wrong or jittery, RTP timestamp bad Fix: Genlock source or enable frame sync if available Encapsulator produces invalid RTP timestamp ( e.g fixed offset, jumps etc.) Investigate whether transient (reboot to fix) or inherent issue in product Some products take a while to settle to a valid RTP timestamp Can be difficult to explain to vendor Conclusions Timestamps are an important part of 2110, receivers need them to match video and audio They can be hard to measure and interpret Maths can cause headaches Timestamps often confused with packet arrival time Need to be measured continually Need to make sure encapsulators have frame syncs or all sources genlocked Need to understand reasons for invalid timestamps Any Questions? Content – no bullets Slide no bullets Bullet 1 Bullet 2 Bullet 3 Bullet 4 Bullet 5 Slide with bullets Image slide Replace text box with image. Delete side panel if image is too large to fit inside text box.