2026-06-02

RTSP SDP H.264 vs H.265: Diagnose No Video

Why RTSP diagnostics should inspect SDP and codec parameter evidence before treating a camera stream as a player compatibility problem.

Many RTSP failures are described as "the camera stream does not play." That phrase hides the most important diagnostic boundary: "what did the camera claim in SDP, and did the media payload match that claim?" SDP is often the first structured evidence available in an RTSP session. It declares media tracks, payload types, codec names, clock rates, control URLs, and codec-specific parameters. If the SDP is wrong, incomplete, or unsupported by the consumer, a stream can fail before the first frame is decoded.

What SDP Should Prove

After DESCRIBE, a client should know whether the stream contains video, which payload type maps to which codec, and how the media track should be set up. For camera diagnostics, inspect:

m=video media section
a=control track URL
a=rtpmap payload type and codec name
a=fmtp codec parameters
H.264 sprop-parameter-sets when present
H.265 VPS/SPS/PPS signaling when available
whether the advertised clock rate is expected

If SDP advertises H.264 but the camera sends something else, the receiver is not being unreasonable. If SDP omits essential parameter evidence and the stream never sends it in-band, the decoder may not have enough information to begin.

H.264 Parameter Sets Are Not Optional Evidence

H.264 decoders need sequence and picture parameter information. In RTSP camera deployments, this evidence may appear in SDP, in-band RTP payloads, or both. Problems appear when a camera assumes the receiver already knows something that it does not know.

A clean diagnostic record answers:

was SPS visible?
was PPS visible?
did payloads include an IDR frame?
did the stream start mid-GOP?
did the profile-level-id look plausible?
did packetization mode match observed payload structure?

This is especially important when one player works and another does not. A tolerant viewer may survive questionable metadata. A recording, analytics, or compliance pipeline may reject it.

H.265 Adds More Compatibility Boundaries

H.265 is common on modern cameras, especially when bandwidth matters, but it is less universally supported than H.264 in older tooling and embedded consumers. H.265 also brings VPS evidence in addition to SPS and PPS. A deployment that only says "RTSP works" may still fail because the actual codec profile or parameter delivery is outside the consumer's supported boundary.

For field teams, a useful article, ticket, or report should not say only "switch to H.264." It should explain why:

the current consumer lacks H.265 support
the H.265 parameter sets are missing or late
the payload type does not match expected codec mapping
the stream is valid but outside the product boundary
the camera profile should be changed for this workflow

That level of clarity prevents repeated trial-and-error changes.

SDP Must Be Compared with RTP

SDP is a claim. RTP is the evidence that follows. The two must be compared.

Examples:

SDP claims payload type 96 is H.264, but RTP arrives with a different payload type.
SDP contains a video track, but no RTP follows PLAY.
SDP says H.265, but the downstream product only supports H.264.
SDP omits parameter sets, and RTP never sends them before slices.
RTP arrives, but NAL unit structure is inconsistent with the advertised codec.

These cases require different next actions. Without comparing SDP and RTP, all of them look like the same vague "no video" failure.

Why RTSP Inspector Surfaces This Evidence

RTSP Inspector is designed for stream engineers, camera vendors, and CCTV integrators who need repeatable evidence. It is intentionally not a generic media player. Its job is to inspect the RTSP control path, SDP metadata, RTP/RTCP flow, and H.264/H.265 readiness.

That makes the output useful in support conversations:

camera vendor: fix SDP or packetization
network team: fix RTP delivery path
VMS team: adjust supported codec profile
field integrator: change stream profile or transport mode
customer: understand why playback is not proof of protocol health

In RTSP diagnostics, SDP is not boilerplate text. It is the first contract the stream offers. If that contract is broken, the rest of the pipeline is guessing.

Read SDP as a contract, not a decoder error

An SDP answer is most useful when it is compared with one explicit question: what is the receiver entitled to expect after PLAY? Start by matching the media section, payload type, codec name, clock rate, control value, and format parameters. Then locate the first RTP packet for that track. This prevents a generic “no video” label from hiding whether the failure occurred before SETUP, before RTP arrival, while waiting for decoder configuration, or during decode.

Observation	First evidence to compare	Most likely boundary	Do not conclude yet
SDP has no `m=video` section	DESCRIBE response and selected profile	The camera did not offer video on this resource	That the network blocked RTP
SDP says H264 but RTP uses another payload type	`a=rtpmap` and RTP payload type	SDP-to-RTP mapping mismatch	That the codec is universally unsupported
SDP says H265 and RTP arrives	Consumer capability and parameter delivery	Codec or decoder-readiness boundary	That RTSP authentication failed
RTP arrives with no decodable first frame	VPS/SPS/PPS, IDR timing, packet structure	Codec configuration or start-mid-GOP issue	That no packets were delivered
SETUP or PLAY fails before RTP	Control URI and transport response	RTSP state or transport failure	That SDP alone is malformed

The table is deliberately ordered by evidence. A player can display a black pane for every row, but the remedy differs: select another stream profile, correct a control path, permit a transport, wait for an IDR, or use a compatible codec path.

Compare each media section with RTP

For every m=video section, make a small record: the advertised payload number, the rtpmap value, any fmtp line, the a=control value, and the first observed RTP packet after PLAY. If the camera offers both audio and video, do not assume packet type 96 in one section has the same meaning as 96 in a different stream profile. The mapping belongs to the SDP for that session.

When payload types disagree, preserve the exact SDP and RTP observation. A dynamic payload number is not inherently wrong; a mismatch between the advertised mapping and the observed packets is the useful finding. If the client never reaches RTP because SETUP is rejected, move back to the RTSP request sequence. The aggregate-control URL workflow is the right branch for a DESCRIBE-successful, SETUP-failing stream.

Clock rate is another evidence field, not a cosmetic number. It affects timestamp interpretation, pacing, and reports of drift. A receiver that uses a different rate may show uneven playback or slowly diverging audio/video even when individual packets arrive. Keep the SDP clock rate beside the RTP timestamp series when investigating long-running streams.

Parameter sets and first-frame readiness

H.264 needs sequence and picture parameter information; H.265 adds VPS evidence alongside SPS and PPS. A stream may be transport-correct yet fail to decode when a receiver joins after those parameter sets were sent, when the camera starts mid-GOP, or when the receiver expects configuration in SDP that the camera sends only in-band. The right observation is not simply “parameter sets missing.” Record where they were expected, where they appeared if at all, and whether a usable key frame followed.

Codec evidence	Why it matters	Safe next test
H.264 SPS/PPS in SDP	Lets a receiver initialize before media	Compare with the first IDR and observed packetization
H.264 SPS/PPS only in RTP	A late join may need an IDR before decode	Start a fresh session and record the first configuration-bearing packet
H.265 VPS/SPS/PPS	Defines the HEVC decode configuration	Check that the consumer actually accepts H.265 for this route
Parameter sets appear after slices	Decoder may reject or wait indefinitely	Capture ordering; do not call it packet loss without evidence
No configuration and no IDR	Decoder lacks a reliable entry point	Change profile, request a keyframe if supported, or inspect camera behavior

RTSP Inspector can retain the control and packet evidence needed to make that distinction. It does not invent a missing parameter set and it cannot certify that an arbitrary downstream decoder supports every H.265 profile. Its value is making the boundary explicit.

Use H.264 and H.265 as separate compatibility paths

H.265 is not merely a newer spelling of H.264. A camera can be healthy, RTP can be continuous, and an older VMS, browser bridge, analytics pipeline, or restreamer can still be unable to consume it. If the main stream advertises H.265 and the sub stream advertises H.264, capture both SDPs and compare the actual RTP arrival. The working sub stream proves reachability and credentials for that profile; it does not prove the consumer can decode or package the main stream.

If the evidence points to a codec boundary, use the H.265 RTSP fallback guide to decide whether a camera-side H.264 profile is the practical solution. Do not call a codec fallback a protocol repair. It is a compatibility decision that may trade bandwidth or storage efficiency for broader live-view support.

A reproducible no-video workflow

Save the DESCRIBE response and identify the selected media section.
Record each rtpmap, fmtp, control value, and advertised clock rate.
Confirm SETUP and PLAY responses before expecting RTP.
Count RTP by payload type and compare it with the SDP mapping.
Record whether H.264 SPS/PPS or H.265 VPS/SPS/PPS appear and when.
Note whether a key frame appears after a new session starts.
Test the same consumer against an H.264 sub stream only when that profile is intentionally comparable.
Keep the conclusion narrow: no packets, mapping mismatch, missing configuration, or unsupported codec path.

This sequence gives a support team something testable. It also stops an operator from changing camera codec, firewall, player, and credentials in one pass and then being unable to explain why the symptom changed.

SDP and codec FAQ

If DESCRIBE returns H.265, is the camera stream valid?

It proves the camera advertised an H.265 media track. It does not prove the selected receiver supports that codec, that configuration arrives in a usable way, or that RTP will reach the receiver after PLAY. Compare SDP, RTSP state, and RTP evidence in that order.

Why does one player show video while my NVR or browser does not?

The successful player may accept a different codec profile, tolerate late parameter sets, use hardware decode, choose a sub stream, or hide protocol warnings. Capture the stream profile and SDP in both cases before assuming the URL itself is different.

Is an RTP payload type mismatch always a camera fault?

No. It could be a camera SDP defect, a proxy rewriting media incorrectly, or a client associating packets with the wrong session. The useful report is the advertised mapping, the observed packet type, and the control/session context.

When is packet loss the right next investigation?

When RTP is expected and observed but sequence gaps, late packets, or RTCP evidence show delivery trouble. If no RTP follows a failed PLAY, or configuration never permits decode, packet-loss analysis is a later branch rather than the first explanation.

Related guides

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