SDP, H.264, and H.265 in RTSP Diagnostics: The Metadata That Decides Whether Video Can Start

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 RtspInspector Surfaces This Evidence

RtspInspector 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.