RTSP Connects but Shows No Video: What to Inspect Before Blaming the Player

One of the most common camera support tickets sounds simple: the RTSP URL connects, authentication succeeds, but the viewer shows no video. The natural instinct is to try another player. That can be useful, but it does not answer the engineering question: did the stream fail at RTSP control, SDP negotiation, RTP delivery, or codec readiness?

For CCTV integrators, VMS engineers, and camera vendors, this distinction matters. A player can hide packet loss, reuse old decoder state, or silently retry transport modes. A diagnostic report should explain which part of the stream was proven healthy and which part was not.

Separate Control Success from Media Success

RTSP is a control protocol. A successful DESCRIBE, SETUP, and PLAY sequence proves that the camera accepted the session. It does not prove that RTP packets arrived. It also does not prove that the payload is actually H.264 or H.265 in the form advertised by SDP.

A useful first pass records:

• the RTSP status codes for OPTIONS, DESCRIBE, SETUP, and PLAY
• whether the SDP body contains a video media section
• the payload type negotiated for the video track
• whether RTP packets arrive after PLAY
• whether the RTP timestamp and sequence numbers move forward
• whether the first video payload contains codec parameter evidence

If control succeeds but no RTP arrives, the problem is usually transport, firewall, NAT, camera mode, or server-side stream availability. If RTP arrives but there is no decode-ready video, the problem shifts toward payload, packetization, or codec metadata.

Why SDP Is the First Evidence Boundary

SDP tells the client what the camera claims it will send. For H.264, engineers look for rtpmap and fmtp values such as packetization mode, profile-level-id, and sprop-parameter-sets. For H.265, the SDP may carry VPS, SPS, and PPS information differently, and many consumers have stricter support limits.

When the SDP says H.264 but the media bytes do not contain expected NAL unit structure, the failure is not a generic "player problem." It is a mismatch between advertised metadata and payload reality. When SDP omits parameter sets and the RTP stream never sends them in-band, a decoder may wait forever.

That is why an RTSP inspection workflow should keep SDP beside the media evidence, not buried in a player log.

RTP Arrival Is Not Enough

Even when RTP packets arrive, the video can still fail. H.264 and H.265 frames often depend on earlier packets. A missing packet can make the next slice undecodable. Out-of-order delivery can look like corruption. A payload that starts mid-GOP may not be decode-ready until the next key frame and parameter set appears.

The minimum evidence to collect is:

• RTP sequence continuity
• timestamp progression
• marker bit behavior
• payload type consistency
• H.264 or H.265 NAL unit categories
• SPS, PPS, and for H.265 VPS visibility
• first key-frame readiness

This explains why "VLC plays it" and "our analytics pipeline rejects it" can both be true. Some viewers recover aggressively. Engineering systems often need standards-clean evidence.

TCP Versus UDP Is a Diagnostic Choice

Switching RTSP transport from UDP to TCP is a common troubleshooting step, but it should not be treated as a cure-all. TCP interleaving can avoid blocked UDP ports and reduce packet loss caused by network policy. It can also hide whether the deployment's intended UDP path works.

A good field report records both attempts:

• RTSP over TCP interleaved: does media arrive?
• RTP over UDP unicast: do packets arrive on the negotiated ports?
• RTCP: does sender feedback show timing and packet counts?

If TCP works and UDP fails, the answer is probably not codec support. It is likely network path, firewall, NAT, or port allocation. If both transports deliver RTP but decode still fails, inspect codec structure.

Where RtspInspector Fits

RtspInspector is built for this exact boundary. It is not trying to become a video player or NVR. It captures the evidence around the RTSP session, SDP, RTP/RTCP flow, and H.264/H.265 readiness so an engineer can explain why "connected" did not become "usable video."

The useful output is not a screenshot of a black player window. It is a repeatable answer:

• RTSP control succeeded
• SDP advertised this codec and payload type
• RTP did or did not arrive
• packet sequence was continuous or broken
• codec parameter evidence was present or missing
• the next action belongs to network, camera configuration, firmware, or stream consumer

That is the difference between watching a stream and diagnosing one.