2026-06-03

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

How to debug H.264 packetization-mode in RTSP SDP, packetization-mode=0 vs 1, Single NAL packets, FU-A fragmentation, STAP-A aggregation, and camera decoder compatibility.

When one RTSP client decodes a camera and another fails, compare the SDP H.264 packetization-mode with the actual RTP payloads. Mode 0 permits single NAL units, while mode 1 allows aggregation and FU-A fragmentation; a stream that advertises one rule and sends another creates a concrete interoperability fault. SDP plus payload inspection can prove that mismatch and identify STAP-A/FU-A use, but it cannot establish every decoder's tolerance for nonconforming media.

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.

Adjacent decoder symptoms such as "SPS PPS missing" and "STAP-A H264 RTSP" point to the same evidence trail.

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.

Build an SDP-to-packet evidence timeline

Do not treat the player error as the primary fact. Preserve the SDP response and a short packet window that includes a decoder start, an IDR frame, and the failure. The goal is to answer one narrow question: does the RTP payload behavior fit the packetization-mode and parameter-set information that the receiver was offered?

Evidence item	What to compare	A meaningful mismatch
SDP payload type	`m=video`, `rtpmap`, and `fmtp` for the selected track	RTP uses a payload type whose H.264 mapping is absent or different
`packetization-mode`	Advertised 0, 1, or omitted	Mode 0 is advertised while FU-A or STAP-A appears in the same stream
First decodable access unit	Single NAL, STAP-A, or FU-A sequence	The receiver never receives a complete NAL start-to-end chain
SPS/PPS source	`sprop-parameter-sets` and in-band parameter sets	SDP is stale and the stream begins with incompatible codec parameters
RTP sequence and marker	Continuity through the affected access unit	A gap or an early boundary splits the NAL that the decoder needs

For example, a camera can successfully answer DESCRIBE, negotiate SETUP, and send RTP, yet still be incompatible when it advertises mode 0 and fragments a large IDR as FU-A. That is a protocol evidence finding. It is stronger than “camera video is black,” but it does not by itself identify which player implementation should tolerate the malformed stream.

Separate a packetization mismatch from packet loss

FU-A is often blamed whenever the first keyframe fails. Verify the fragment chain before changing a camera setting or lowering bitrate. A correct mode-1 stream can still fail because one UDP packet was lost; an intact stream can fail because the receiver was configured for the wrong mode.

Observation	Most likely interpretation	Next check
FU-A start, middle, and end are contiguous; SDP says mode 1	Fragmentation is expected	Compare the reconstructed NAL and decoder configuration
FU-A appears but SDP says mode 0	SDP and payload contradict each other	Save SDP plus first FU-A header for the camera/gateway owner
FU-A start exists but end is missing with a sequence gap	Packet loss can prevent reconstruction	Inspect loss, retransmission policy, and UDP path behavior
Only large motion/keyframes fail	Frame size or MTU pressure is implicated	Compare packet count and loss around IDR versus P-frames
STAP-A carries parameter sets but the receiver starts late	Decoder initialization timing may be wrong	Check whether parameter sets repeat before later IDRs
TCP interleaved works while UDP fails	Network delivery, not packetization syntax alone, is implicated	Compare the same access unit over both transports

The RTP marker-bit guide explains access-unit boundaries, while the RTSP UDP versus TCP troubleshooting guide helps test a transport-path hypothesis without pretending that TCP repairs an incorrect SDP.

Capture procedure for a reproducible compatibility report

Save the complete DESCRIBE SDP before reconnecting or changing camera encoding settings.
Record selected RTSP transport, payload type, codec profile, resolution, bitrate, and the affected client version.
Capture from before the first IDR until after the first visible decoder error; avoid a payload filter that removes FU-A or STAP-A headers.
Mark the first failing access unit and list its RTP sequence range, timestamp, marker-bit location, and NAL form.
Repeat exactly once with the same stream over the alternate supported transport if that changes the symptom.
Redact credentials and private camera addresses, then preserve SDP and packet metadata together so another engineer can test the same assertion.

Does a missing `packetization-mode` mean mode 1?

No. It means the client must use the relevant compatibility behavior and the trace must show what the sender actually emitted. Do not silently rewrite a missing value to mode 1 in a support conclusion.

Does lowering bitrate prove an H.264 packetization bug?

No. It can reduce large NAL fragmentation and packet loss, so it is a useful experiment rather than proof. Compare the SDP and FU-A/STAP-A evidence before assigning cause.

What can RTSP Inspector establish?

It can correlate SDP, RTP payload structure, sequence continuity, timestamps, and transport context in the captured session. It cannot prove an unobserved decoder's implementation detail or repair camera firmware.

Debug checklist

Use this process:

Read the SDP rtpmap and fmtp lines.
Find packetization-mode.
Check whether it is missing, 0, or 1.
Inspect actual RTP H.264 payload structures.
Look for FU-A fragmentation.
Look for STAP-A aggregation.
Compare SPS/PPS in SDP with RTP payloads.
Check sequence gaps inside fragmented NAL units.
Correlate decoder errors with keyframes.
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.

How do you prove the H.264 packetization mode is compatible?

Retain the complete video media section from SDP and a bounded RTP window beginning before an IDR frame. Record payload type, clock rate, packetization-mode, profile-level identifier, parameter-set signaling, MTU-related packet sizes, NAL unit types, marker bits, sequence continuity, and the receiver’s first decoder result. The advertised mode and observed packetization must agree.

SDP/RTP condition	Mode 0 expectation	Mode 1 expectation
Single NAL unit packets	Allowed	Allowed
FU-A fragmentation	Not allowed by mode 0	Commonly allowed
STAP-A aggregation	Not allowed by mode 0	May be used
Oversized NAL handling	Sender must avoid unsupported fragmentation	Sender may fragment correctly
Receiver policy	Reject or handle only permitted forms	Reassemble and validate permitted forms

Run a known-working client with the same camera profile as a comparison, then test the corrected sender or receiver on a fresh session. A player that silently tolerates an SDP/RTP mismatch is useful control evidence but does not make the stream specification-compliant. Likewise, changing to a lower-resolution profile can avoid fragmentation while hiding the original incompatibility.

Acceptance should show that the SDP mode, actual NAL packaging, sequence/marker boundaries, parameter sets, and first decodable keyframe align. Keep failed and successful windows in the same RTSP report, and use the FU-A reassembly guide if the failure occurs inside fragment ordering rather than mode negotiation.

Record camera firmware, profile, resolution, bitrate, and the largest observed RTP payload in both runs. If lowering resolution removes FU-A packets, label that as a workaround comparison, not proof that the original mode mismatch has been corrected. Retest the original profile before closing the case.

Preserve that original-profile acceptance window with the exact SDP returned on the successful connection.

Related guides

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