Why split them at all
Because most of the time you do not want all of it. A multiviewer needs pictures but not every audio channel. An audio mixer needs sixteen channels and no video whatsoever. A subtitle system needs the ANC stream alone, a few kilobits instead of gigabits. Separating essences means each device subscribes only to what it uses, and the network carries each stream once regardless of how many receivers want it.
It also means routing happens per essence. Swapping the audio on a feed without touching the video is a configuration change, not a hardware path, which is exactly the flexibility the suite was designed for.
What holds them together
Only two things: every sender disciplines its clock to the same PTP grandmaster, and every packet carries an RTP timestamp derived from that clock. A receiver collects the essences it subscribed to and aligns them by those timestamps. There is no container, no interleaving, no inherent ordering; the alignment is reconstructed at the far end from timing information alone.
That is why the timing guide matters more than it appears to: in ST 2110, a clock problem is a sync problem, and a sync problem surfaces as a content problem.
The three essences in practice
ST 2110-20: video
Uncompressed, sent as line fragments with a payload header that places each fragment in the raster. The parameters that matter are resolution, frame rate, sampling and bit depth; these live in the SDP rather than in the packets, so a receiver that was told the wrong thing will decode garbage from a perfectly healthy stream.
ST 2110-30: audio
PCM audio in small, frequent packets. The packet time is a deliberate trade: shorter packet times reduce latency and increase packet rate, longer ones do the opposite. Sender and receiver must agree on packet time as well as channel count and sample rate. A mismatch here is one of the more common interoperability failures, and it usually presents as no audio rather than as bad audio.
ST 2110-40: ancillary data
The metadata that used to ride in the SDI blanking: timecode, closed captions and subtitles, AFD and similar. It is sparse and bursty by nature: nothing at all for long stretches, then a packet on a specific line of a specific frame. Sparse traffic is easy to lose without anyone noticing until a caption is late.
Transport activity does not prove useful content. A PCM audio stream can continue carrying packets while its samples contain digital silence. If a sender stops transmitting, packet counters can reveal the loss of transport. Decode the essence and inspect its content alongside the transport statistics. For ANC, interpret sparse traffic in the context of the expected metadata.
Where it goes wrong
| Symptom | Usual cause |
|---|---|
| Lip sync drifts slowly over minutes | Video and audio senders disciplined to different references, or one not locked at all |
| Audio present, wrong channels | Channel order or channel count mismatch between sender and receiver; the SDP describes it, the packets do not |
| No audio, video fine | Packet time mismatch, or the audio group never joined because it is a separate multicast address |
| Captions land a frame or two late | ANC timestamps misaligned with video, often after a timing event nobody noticed |
| Timecode jumps at a regular interval | The ANC sender is deriving time from a clock that is stepping rather than slewing |
How to verify alignment properly
- Confirm all senders follow the same PTP domain and grandmaster before anything else.
- Inspect decoded content alongside packet statistics. Normal packet activity does not by itself prove useful audio, moving video or the expected ANC data. The 2110 Toolkit's ST 2110 analyzer shows both side by side.
- Compare RTP timestamps between the video and audio streams of the same source; a fixed offset is a configuration matter, a growing one is a clock matter.
- Check that the receiver actually joined every group it needs, since a missing essence is a missing join far more often than a missing stream.
- Read the SDP for each essence and compare it against what the receiver expects. Most "no audio" reports end here.