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.

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.

A capture can contain continuous RTP traffic while the decoder still stutters, waits for a keyframe, or cannot form clean H.264 access units. Correlate marker bits with RTP timestamp changes, sequence gaps, FU-A start/end flags, NAL types, and IDR arrival instead of treating every marker as an independent frame boundary. That packet evidence can locate a missing fragment or inconsistent marker convention; it cannot prove decoder behavior once a complete access unit leaves the network layer.

RTSP Inspector 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:

Confirm SDP maps payload to H.264.
Track RTP sequence numbers.
Group packets by RTP timestamp.
Inspect marker bit at frame boundaries.
Identify FU-A start/end fragments.
Look for packet loss before marker packets.
Identify IDR keyframes and SPS/PPS.
Compare stutter time with sequence gaps.
Compare UDP and TCP interleaved transport.
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.

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

Build an access-unit timeline, not a marker-bit counter

The RTP marker bit is meaningful only in payload-format context. For common H.264 RTP use it is often set on the last packet of an access unit, but one marker does not prove that a receiver formed a decodable image. Group packets by SSRC, payload type, RTP timestamp, sequence continuity, and H.264 packetization evidence before correlating the result with a stutter or freeze.

Evidence field	Question	Why it matters
SSRC	Are packets from one source grouped together?	A source change can look like a loss gap
Payload type	Does SDP map it to H.264?	Marker bits cannot be interpreted without mapping
RTP timestamp	Which packets form one candidate access unit?	Timestamp changes provide a second boundary clue
Sequence number	Is the range contiguous?	A missing packet can make a NAL incomplete
Marker bit	Which packet claims to end the unit?	It aligns a candidate end, not successful decoding
NAL/FU-A flags	Did a fragment start and end correctly?	Shows whether payload can be reconstructed
IDR/SPS/PPS evidence	Is recovery material present?	Explains long freezes after loss

RTSP Inspector can report these protocol facts. It cannot claim that a decoder displayed a frame without receiver evidence, so keep packet observation and player behavior as separate fields in a case report.

H.264 packetization changes the meaning of a loss

A small NAL unit can be carried in one RTP packet. A larger unit can use FU-A fragmentation, which requires a start fragment, ordered middle fragments, and an end fragment. A marker bit on the last packet does not repair bytes that disappeared earlier in a fragmented NAL.

Observation	Diagnostic interpretation
Single NAL packets with marker on last timestamp group	Simple candidate access-unit boundary
FU-A start, contiguous sequence, FU-A end with marker	Candidate fragmented NAL completed
FU-A end after a sequence gap	NAL is incomplete even if a marker exists
Several markers under one timestamp	Sender convention needs NAL and sequence comparison
Timestamp changes before a marker	Loss or unusual framing needs closer inspection
Missing/odd payload mapping	Confirm SDP before calling it H.264 behavior

Use SDP H.264/H.265 diagnostics to verify payload mapping and packetization assumptions. A wrong mapping can look like a framing problem when the client is actually interpreting the wrong media format.

Place loss inside the media structure

Loss is useful evidence only when its position is known. A gap in a normal inter-frame picture may cause local corruption; a gap inside an IDR or parameter-set sequence can delay recovery until the next usable keyframe. A missing marker packet may hide an expected boundary, but inspect the whole timestamp group rather than treating the final packet as the only relevant packet.

Loss pattern	Likely consequence	Next test
Gap in a non-IDR timestamp group	Local corruption or dropped picture	Compare the next timestamp group
Gap in a FU-A chain	Incomplete NAL	Record start/end flags and missing sequence
Gap near IDR/keyframe fragments	Freeze until later recovery point	Find next IDR and parameter sets
Marker packet absent	Receiver may miss expected end boundary	Compare timestamp transition and following frame
RTP continuous but no IDR for long period	Slow recovery may be encoder/profile related	Record keyframe cadence
No gap at this capture point	Loss may occur elsewhere or issue may be consumer policy	Compare another point or client log

The RTP packet loss camera stream guide is the next path for sequence-gap investigation. Do not change bitrate, GOP, or codec profile until the capture establishes where the missing packet is real.

Correlate timestamps, keyframes, and stutter carefully

RTP timestamps commonly stay constant within an access unit and advance for the next one, but their scale comes from SDP clock rate rather than wall-clock time. Compare timestamp behavior with sequence continuity, marker pattern, NAL evidence, and any receiver-side event at the same time. Keep a window beginning before a visible stutter and ending after the next recovery candidate.

Checkpoint	Evidence to retain
Last good unit	Timestamp, sequence range, marker, and NAL type if visible
First damaged unit	Gap or unusual framing relation
Recovery candidate	IDR/keyframe and parameter-set context
Next good unit	Shows whether recovery followed a network or encoder boundary
Transport comparison	UDP or TCP interleaved result with same camera profile
Capture point	Interface, path, and test time

For long-run clock problems, see RTP timestamp drift and clock-rate diagnostics. Drift is not the same as a single access-unit reassembly failure, even though both involve timestamps.

A bounded workflow for RTSP stutter

Confirm the SDP maps the selected payload type to H.264.
Isolate one SSRC and a short window around the stutter.
Group packets by timestamp and record each sequence range.
Locate gaps relative to FU-A start/end and marker packets.
Identify IDR/keyframe and parameter-set evidence near the damage.
Compare one good unit with the first bad unit.
Repeat through TCP interleaved if the environment allows it.
Report the packet fact separately from the unproven decoder cause.

The UDP/RTP firewall and NAT guide is useful when transport changes loss behavior. If RTP remains healthy but the consumer fails before media interpretation, continue with RTSP connects but no video.

FAQ: RTP marker bits and H.264 reassembly

Does a marker bit always mean the end of a video frame?

No. It is payload-format specific and should be read with timestamp, sequence, NAL, and SDP evidence. For common H.264 RTP it is a useful end-of-access-unit clue, not proof of a complete decodable frame.

Can a marker-bit issue explain a long freeze?

It can contribute when combined with loss or malformed framing, but duration can also depend on keyframe interval, missing IDR fragments, parameter sets, or decoder policy. Preserve the next recovery point before claiming a cause.

What should I send to a camera or NVR vendor?

Provide the SDP, payload type, SSRC, timestamp and sequence range, marker pattern, FU-A/NAL observation, exact loss position, transport, and a concise before/after comparison. That makes the protocol question reproducible without claiming the trace proves an internal encoder defect.

How do you validate H.264 access-unit boundaries?

Choose a window containing several ordinary frames and at least one IDR. Group RTP packets by SSRC and timestamp, then inspect sequence continuity, NAL or FU-A type, start/end fragments, marker bit, and timestamp transition. The marker bit is a sender signal about the end of an access unit under the payload format; it is not a universal “this packet is a keyframe” flag.

Boundary clue	What it supports	What it does not prove alone
Shared RTP timestamp	Packets may belong to one sampling instant	Every packet belongs to one valid NAL/frame
Marker bit	Sender indicates end of access unit	Packet contains IDR or decoder can display it
FU-A start/end	Fragmented NAL boundaries	No fragment was lost or reordered
NAL type 5	IDR NAL evidence	SPS/PPS and all required slices are available
Timestamp change	Next sampling instant begins	Previous frame was complete

Reproduce the symptom and preserve the first incomplete or contradictory group plus the next clean recovery point. Compare a known-working receiver to identify tolerance differences, but do not rewrite the stream’s actual marker behavior in the report. If one missing fragment prevents an access unit from completing, state the exact sequence gap and affected timestamp.

Acceptance shows consistent grouping, valid fragment boundaries, required parameter sets, and a decodable recovery point after loss. Keep the bounded timeline in an RTSP Inspector report and use the FU-A reassembly guide for byte-level fragment validation.

Compare several consecutive access units, not only the one that failed. A sender that marks every RTP packet, never marks a completed unit, or changes policy mid-stream may occasionally produce a decodable frame while still violating the receiver’s boundary assumptions. Note the pattern and its duration.

If the receiver recovers only at the next IDR, record the IDR interval and whether SPS/PPS were available at that point. That bounded recovery statement is more useful than saying the marker bit “caused black video.”

Retain the receiver version and exact camera profile with that conclusion for a reproducible retest.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: