IBC 2022 IP Showcase - Timestamps in ST 2110: What They Mean and How to Measure Them

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
1st 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!

 Left: Packet arrival time relative to PTP alignment point
 Right: RTP timestamp relative to PTP alignment point
 Either could be wrong!

 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
PTP offset 11.111us (1 rtp) – Packet arrival GOOD, RTP Timestamp OK
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 (1st 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

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.

IBC 2022 IP Showcase - Timestamps in ST 2110: What They Mean and How to Measure Them

More Related Content

What's hot (20)

Similar to IBC 2022 IP Showcase - Timestamps in ST 2110: What They Mean and How to Measure Them (20)

More from Kieran Kunhya (16)

Recently uploaded (20)

IBC 2022 IP Showcase - Timestamps in ST 2110: What They Mean and How to Measure Them

Editor's Notes