Start with the arithmetic
A single 1080p59.94 ST 2110-20 stream is roughly 3 Gb/s of payload. That is about 375 MB every second, 22 GB a minute, and well over a terabyte an hour — for one stream. A 2022-7 pair doubles it. Capturing "just in case" is therefore not a strategy, and a capture that drops packets under its own weight produces evidence that cannot be trusted: you can no longer tell a network loss from a capture loss.
Three approaches survive contact with real bitrates:
- Ring buffer. Keep the last few seconds in memory and write them out when something interesting happens. This matches how faults are actually noticed — after the fact.
- Filter hard at capture time. One multicast group, one port; discard everything else before it reaches the disk.
- Capture the small streams in full. Audio in ST 2110-30 and ANC in ST 2110-40 are orders of magnitude smaller than video, so for timing and metadata questions you rarely need the pixels at all.
Capture where the problem is, not where it is convenient. A SPAN or mirror port shares fate with the switch's own buffering: it can drop, reorder and re-time the traffic you are measuring. For pacing questions especially, a capture taken at the receiving NIC reflects what the receiver actually experienced. A mirror tells you something adjacent to the truth.
What the headers tell you
Once a capture is open, most ST 2110 questions are answered by four fields, shown in the diagram above. The sequence number reveals loss and reordering. The RTP timestamp groups packets into frames and states when the frame was meant to be presented. The marker bit ends a frame. The payload header places the fragment in the raster.
Practical readings that follow from those fields:
| Observation | Reading |
|---|---|
| Sequence gaps, no reordering | Genuine loss — a queue somewhere discarded packets |
| Sequence out of order, nothing missing | Reordering, often from a redundant path or link aggregation hashing the flow across members |
| Uneven arrival times within a frame | Pacing, not loss — see the ST 2110-21 guide |
| Packet count per frame varies wildly | Either a different packing mode than expected, or you are looking at two senders on the same group |
| RTP timestamp drifts against PTP | The sender's clock discipline, not the network |
Wireshark, honestly
Wireshark is excellent at what it is: a packet dissector. It will decode ST 2110-20 headers and let you filter a stream apart, and recent versions have grown better support for the suite. What it does not do is show you the picture, draw a waveform, or tell you whether a sender meets a shaping requirement — those are media questions rather than packet questions.
The practical division of labour: capture and analyse media behaviour with a tool that understands essences, and export to Wireshark when the question turns into a packet-level or vendor-dispute question. Having the capture taken at the same point as the analysis is what makes the two views agree.
Keep the SDP with the capture
A pcap of uncompressed video is not self-describing. Sampling, bit depth, resolution, frame rate and packing determine how the payload should be interpreted, and they live in the SDP — not in the packets. A capture archived without its SDP is dramatically less useful six months later when a vendor asks for evidence.
For the same reason, capture the PTP traffic alongside the media when the question is about timing. Media packets alone cannot tell you whether a timestamp was wrong or the clock was.
A workflow that works
- Decide the question first: loss, pacing, timing or format. Each needs a different capture.
- Filter to the specific multicast group and port before capturing anything.
- Run a ring buffer and export when the symptom appears, rather than capturing continuously and hoping.
- Record the SDP and the PTP state at the same moment.
- Verify the capture is clean — if the tool reports its own drops, fix that before drawing conclusions.