2026-06-02

RTP Marker Bit and H.264 Frame Boundaries: Debugging RTSP Stutter, Missing Keyframes, and Reassembly

How to diagnose RTP marker bit behavior, H.264 frame boundaries, IDR keyframes, RTP timestamps, FU-A fragments, packet loss, and RTSP video stutter.

rtp marker bit, h264 frame boundary, rtsp stutter, idr keyframe, fu-a fragmentation, rtp diagnostics

H.264 over RTP depends on more than just receiving packets. The receiver must group payloads into frames, handle fragmented NAL units, detect access-unit boundaries, and recover after packet loss. The RTP marker bit is one of the clues used to identify the end of a video frame. When marker behavior is wrong or packet loss removes the final fragment, video can stutter, freeze, or show corruption.

Users search for "RTP marker bit H264", "H264 frame boundary RTP", "RTSP stutter marker bit", "missing keyframe RTP", and "H264 IDR over RTP troubleshooting" because the stream may contain packets but not clean frames.

RtspInspector is useful because marker bit, RTP timestamp, sequence number, and H.264 NAL structure must be seen together.

What the marker bit means

In RTP, the marker bit is payload-format specific. For many video payloads, it marks the end of an access unit or frame. For H.264 packetization, it is commonly set on the last RTP packet of an access unit.

A simple frame may look like:

Seq 1000 timestamp 90000 marker 0
Seq 1001 timestamp 90000 marker 0
Seq 1002 timestamp 90000 marker 1

All packets share the same timestamp. The marker bit on the last packet indicates frame boundary.

Marker bit is not enough alone

Do not diagnose H.264 frame boundaries from marker bit alone. Also inspect:

  • RTP timestamp
  • RTP sequence number
  • Payload type
  • NAL unit type
  • FU-A start/end bits
  • SDP packetization mode

Some cameras behave loosely. Some set marker bits inconsistently. A robust diagnosis compares all available evidence.

Missing marker packet

If the final RTP packet of a frame is lost, the marker bit may be lost too. The receiver may wait, flush late, or drop the incomplete frame.

Symptoms:

  • Stutter on packet loss.
  • Frame delay until next marker.
  • Corrupt frame passed to decoder.
  • Long freeze until next IDR frame.

This is why RTP sequence gaps around marker packets are especially important.

Keyframes and IDR frames

After packet loss, video often recovers at the next IDR keyframe. If IDR interval is long, corruption can last longer. If keyframe packets are fragmented and one fragment is lost, recovery may fail until the next keyframe.

Look for:

  • IDR NAL units.
  • FU-A fragments carrying IDR.
  • Missing sequence numbers inside IDR.
  • Marker bit at keyframe boundary.
  • SPS/PPS availability near keyframe.

Debug checklist

Use this workflow:

  1. Confirm SDP maps payload to H.264.
  2. Track RTP sequence numbers.
  3. Group packets by RTP timestamp.
  4. Inspect marker bit at frame boundaries.
  5. Identify FU-A start/end fragments.
  6. Look for packet loss before marker packets.
  7. Identify IDR keyframes and SPS/PPS.
  8. Compare stutter time with sequence gaps.
  9. Compare UDP and TCP interleaved transport.
  10. Preserve packet evidence around visible stutter.

Final diagnosis

RTP marker bit problems are frame-boundary problems. The decoder needs complete access units, not just a stream of packets. Marker bit, RTP timestamp, sequence number, FU-A structure, and keyframe evidence explain why an RTSP H.264 stream stutters or freezes.

RtspInspector helps expose those media-layer details instead of hiding them behind generic playback failure.