H.264 RTP Packetization Mode 0 vs 1 in RTSP SDP: Single NAL, FU-A, STAP-A, and Camera Compatibility

H.264 over RTP is not just "send video packets." The SDP packetization-mode controls how NAL units can be carried. Users search for "H264 packetization-mode 0", "H264 packetization-mode 1", "RTSP FU-A not supported", "Single NAL unit mode", "STAP-A RTP H264", and "camera H264 SDP packetization mode" when one client decodes the stream and another fails.

RTSP Inspector is useful because packetization mode is an SDP and RTP compatibility issue. A player may only show black video. The trace can show whether the stream advertised mode 0 but used fragmentation, or advertised mode 1 but the receiver only accepted single NAL packets.

Why packetization mode matters

H.264 RTP payloads can be sent in different ways:

• Single NAL unit packets.
• Fragmentation units such as FU-A.
• Aggregation packets such as STAP-A.

The SDP fmtp line may include:

a=fmtp:96 packetization-mode=1;profile-level-id=42e01f;sprop-parameter-sets=...

If packetization-mode is omitted, clients may assume a default behavior. If the sender and receiver disagree, decoding can fail even though the RTSP session and RTP transport are working.

packetization-mode=0

Mode 0 is Single NAL Unit mode. It is simple but limited. It does not allow FU-A fragmentation or STAP-A aggregation in the same way mode 1 does.

Symptoms when mode 0 is involved:

• Small video works but large frames fail.
• Stream works at low resolution but fails at high resolution.
• IDR frames exceed MTU.
• Sender fragments even though SDP suggests single NAL behavior.
• Receiver rejects fragmented NAL units.

Searchers often describe this as "H264 stream works only at low bitrate" or "RTSP video breaks on keyframe."

packetization-mode=1

Mode 1 is non-interleaved mode. It commonly supports FU-A fragmentation and STAP-A aggregation. Most practical RTSP camera streams use this style because frames can exceed a single network packet.

Evidence to check:

• packetization-mode=1 in SDP.
• FU-A packets for large NAL units.
• STAP-A packets carrying SPS/PPS.
• Marker bit at access unit boundary.
• Sequence continuity across fragments.
• Correct reconstruction of start and end fragments.

If a receiver does not support FU-A correctly, video may fail only on large frames.

Missing packetization-mode

Some cameras omit packetization-mode. Clients then guess. One client may assume mode 1, another may behave more strictly.

This creates compatibility reports like:

• "VLC plays camera but SDK does not."
• "FFmpeg works but browser gateway does not."
• "NVR shows black screen but snapshot works."
• "RTSP stream fails after first keyframe."

The correct diagnosis is to compare SDP advertisement with actual RTP payload types.

FU-A fragmentation evidence

FU-A is used when a large H.264 NAL unit is split across multiple RTP packets. A valid FU-A sequence has:

• Start fragment.
• Middle fragments.
• End fragment.
• Same NAL identity reconstructed from headers.
• Consecutive RTP sequence numbers unless packet loss occurs.
• Marker bit usually on the final packet of an access unit.

If the start fragment is missing, the decoder cannot reconstruct the NAL. If the end fragment is missing, the frame remains incomplete. If the stream advertises a mode that forbids this behavior, the sender and SDP disagree.

STAP-A aggregation evidence

STAP-A can carry multiple small NAL units in one RTP packet, often SPS and PPS. This can help a receiver initialize the decoder.

Potential issues:

• Receiver does not parse STAP-A.
• Camera sends SPS/PPS only inside STAP-A.
• SDP sprop-parameter-sets is missing or stale.
• STAP-A appears after decoder already failed.
• Gateway strips or rewrites fmtp but not payload.

For SEO, "SPS PPS missing" and "STAP-A H264 RTSP" are valuable adjacent keywords.

MTU and keyframe problems

Large IDR frames often trigger fragmentation. A stream may look fine until the first keyframe or until motion increases bitrate.

Evidence:

• Keyframe produces many FU-A packets.
• Packet loss occurs inside one fragmented NAL.
• Decoder error appears after missing fragment.
• Lowering resolution or bitrate makes issue disappear.
• TCP interleaving works better than UDP on a lossy path.

This is not just a codec issue. It connects RTP packetization, network MTU, packet loss, and decoder recovery.

Debug checklist

Use this process:

1. Read the SDP rtpmap and fmtp lines.
2. Find packetization-mode.
3. Check whether it is missing, 0, or 1.
4. Inspect actual RTP H.264 payload structures.
5. Look for FU-A fragmentation.
6. Look for STAP-A aggregation.
7. Compare SPS/PPS in SDP with RTP payloads.
8. Check sequence gaps inside fragmented NAL units.
9. Correlate decoder errors with keyframes.
10. Save SDP and boundary RTP packets together.

Final diagnosis

H.264 RTSP compatibility depends on what SDP advertises and what RTP actually carries. packetization-mode=0, packetization-mode=1, FU-A, STAP-A, SPS/PPS, MTU, and keyframe fragmentation all affect whether a receiver can decode the stream.

RTSP Inspector helps diagnose these failures as protocol evidence instead of vague "black video" reports.