Summary
- RFC 3189 made the RTP marker bit a useful last-packet hint for DV video, but explicitly required receivers to detect a new frame from a changed 90 kHz timestamp because the marked packet itself might be lost.
- The rest of the payload format kept equally important distinctions intact: an RTP packet held integral 80-byte DIF blocks from one frame only; clocks advanced across intentionally discarded frames; error concealment could repeat an older block without recovering the missing one; and SDP could not replace indispensable VAUX and AAUX metadata carried in the stream.
A tape format entered a packet network
Digital Video arrived at RTP with a physical past. The consumer IEC 61834 family had been designed around helical-scan cassette recording. Professional relatives used SMPTE formats. Their data was not born as an arbitrary byte stream waiting to be divided by an IP stack. A picture frame already contained DIF sequences; each sequence was built from 80-byte DIF blocks whose identifiers said whether they carried a sequence header, subcode, video auxiliary information, audio or video.
RFC 3189 did not erase that structure. It placed integral DIF blocks directly after the ordinary RTP header and added no DV-specific payload header. Payload length had to remain a multiple of 80 bytes. A packet could contain several blocks, but every block in that packet had to belong to the same video frame. Even if room remained, a sender could not use it for the first block of the next frame.
That last restriction was not decorative neatness. It made the RTP timestamp the boundary between pictures. Every packet in one frame carried the same 90 kHz timestamp. The next frame changed it by the interval appropriate to the mode. The standard was converting a recording format into a real-time transport without permitting packet packing to blur the unit that playout depended on.
The bit that was helpful precisely because it was not final
RTP already had a marker bit. RFC 3189 assigned it a simple job: zero on ordinary packets, one on the final packet of the video frame. If that packet arrived, a receiver did not need to wait for the first packet with a new timestamp before displaying the picture. The marker could therefore remove a small but real interval of uncertainty from the playout path.
Then came the sentence that defines the design. Frame-change detection must not rely on the marker bit, because the final packet might be lost. A receiver had to use a difference in RTP timestamp.
The distinction is sharper than “use both.” The marker describes a packet that was received. It is evidence that the sender marked this packet as last. When no marker is present, the receiver has two incompatible possibilities: the frame is still arriving, or the packet carrying the marker disappeared. Absence cannot decide between them. The timestamp on a later packet can.
That makes the marker a latency optimization and the timestamp a state boundary. Systems often fail when an optimization is promoted into an authority. Here the standard prevented that promotion in one sentence.
A new timestamp did not complete the old picture
The timestamp answered which frame a packet belonged to. It did not prove that every block of the preceding frame arrived. Sequence numbers could expose gaps, but the payload format also anticipated incomplete pictures and deliberate omission.
A sender could reduce the frame rate by dropping video and VAUX data for selected frames. The timestamp still had to advance for the time that had passed. It could also omit video DIF blocks for regions unchanged from the previous picture. Receivers were encouraged to conceal lost or missing regions by repeating the corresponding block from the preceding image.
That strategy could produce a watchable picture. It could not recreate the absent source block. A smooth screen was therefore not a receipt for complete transport. The clock could be correct while media was missing; the displayed region could look stable because an older region had been substituted.
The standard did not treat this as dishonesty. Real-time systems have deadlines. A late perfect block may be less useful than a timely approximation. But the approximation and the source remained different evidence.
Negotiation described the stream; auxiliary packs made it decodable
DV could carry audio and video together in one RTP stream or separate them. That choice was attached to the dynamic payload type and had to remain stable for the session, avoiding the complexity of resynchronizing sequence spaces during a mode change. Different DV encodings needed different dynamic payload types.
SDP advertised the encoding and whether audio was bundled. Yet the document refused to enumerate every source attribute in session descriptions. Aspect ratio, picture position, audio sampling, channel assignment and language lived in DV source and source-control packs. The sender therefore had to carry the necessary VAUX or AAUX information in the media stream itself.
The split assigned different jobs to different surfaces. SDP said what kind of session was being offered. RTP payload type selected a format. Auxiliary packs supplied the concrete information required to interpret the material. Packets still had to arrive. None of those statements alone proved successful decoding.
Unbundled audio made the same point. RFC 3189 recommended repackaging extracted audio into DAT12, L16 or L20 when doing so improved interoperability with receivers that did not understand DV. If audio and video both remained in DV streams, matching timestamps simplified lip synchronization, while RTCP reference timestamps offered another route. A shared timebase was coordination evidence, not proof that listeners received every sample.
The replacement preserved the warning
RFC 6469 replaced RFC 3189 in 2011. It added high-definition SMPTE 370M modes, offer/answer guidance and source-specific multicast advice. It treated SMPTE 306M names as legacy compatibility material already covered by SMPTE 314M, clarified omitted subcode behavior and corrected the earlier document's improper SDP fmtp examples.
It did not remove the marker warning. The replacement again said the last-packet marker could speed display, but frame detection must use the RTP timestamp because the marked packet might be lost. That continuity matters. The correction history changed registration and negotiation details without abandoning the original loss model.
RFC 6469 also preserved paths for older implementations. A legacy SMPTE 306M offer could still be accepted or retried even though new descriptions should prefer the later label. Succession did not require pretending installed syntax had never existed.
What RFC 3189 actually proved
RFC 3189 proved that DV could be packetized with an agreed relationship among DIF blocks, RTP timestamps, marker bits, payload types and auxiliary metadata. It did not prove that a particular stream was complete, authentic, intelligible, synchronized, secure or archived.
The durable lesson is not that marker bits are unreliable. It is that a field can be reliable within its stated claim and dangerous outside it. When the marked packet arrives, the bit does useful work. When it does not arrive, the protocol needs another observable boundary. The Internet carried tape video successfully by refusing to let one convenient signal speak for evidence it could not contain.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
