2026-06-02

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

A practical diagnostic path for RTSP camera streams that authenticate and connect but still show a black screen or no decoded video.

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 RTSP Inspector Fits

RTSP Inspector 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.

Use a four-boundary triage table

“Connected” is a poor incident label because it can describe a TCP socket, an authenticated RTSP session, a negotiated media track, or a decoded frame. Each means something different. Put the evidence in a fixed order before changing players, camera profiles, or firewall rules.

Boundary	What proves it	What it does not prove	Next place to inspect
RTSP control	Valid `DESCRIBE`, `SETUP`, and `PLAY` responses	That RTP was delivered or decodable	SDP and selected transport
SDP agreement	A video `m=` section with payload type and codec parameters	That the sent RTP payload matches the description	`rtpmap`, `fmtp`, and first payloads
Media delivery	RTP sequence/timestamp progression after `PLAY`	That frames contain a usable key frame and parameter sets	loss, packetization, VPS/SPS/PPS, marker bit
Decode readiness	A parameter set and key-frame path appropriate to the advertised codec	That every downstream viewer supports the stream profile	decoder capability and product integration

This layout also makes a field report useful to more than one team. A network team can act on “no UDP RTP arrived after successful SETUP.” A camera firmware team can act on “SDP advertised H.265 payload type 96, but no VPS/SPS/PPS was visible before the first IDR.” A VMS team can act on “RTP was continuous over TCP interleaving but the requested decoder profile is unsupported.” None of those teams benefits from a conclusion that only says “black screen.”

Compare transports without erasing the diagnosis

Test TCP interleaving and UDP as separate observations. For UDP, retain the Transport header from SETUP, the client/server port pairs, and the first RTP/RTCP packets. For TCP, retain the interleaved channel numbers and the RTSP connection that carries them. If TCP works but UDP does not, do not call it a codec fix: the evidence points to a UDP path, port policy, NAT mapping, or firewall. If both paths carry the same broken payload, transport is less likely to be the primary failure.

The first frame is often misleading. A client that joins in the middle of a GOP can receive valid RTP packets before it receives decoder configuration or an IDR frame. Measure the interval from PLAY to the first parameter-set evidence and first key-frame candidate. If that interval never closes, ask the camera to force a key frame and compare a fresh capture. If it closes only after a long time, document the GOP/IDR behavior instead of treating the first few black seconds as packet loss.

Questions teams should settle before escalation

Can a successful DESCRIBE prove that a video track exists? It proves the server returned an SDP description. Check for the selected video media section, payload type, control URL, and actual RTP after PLAY; a stale or incomplete SDP can still lead to no usable video.

Can arriving RTP prove H.264 or H.265 is correct? No. It proves packets arrived. The payload type, packetization, NAL-unit structure, and configuration evidence must agree with SDP. Use the SDP H.264/H.265 diagnostic guide when the advertised codec and bytes disagree.

What is the minimum vendor handoff? Provide the sanitized RTSP method sequence, SDP, negotiated transport, first RTP/RTCP timing, loss/reordering observation, and a statement of whether VPS/SPS/PPS and an IDR were seen. The RTSP troubleshooting page and the UDP firewall/NAT analysis are useful next steps when the failure boundary is transport rather than codec.

Make one conclusion per failed boundary

An incident closes faster when its conclusion remains falsifiable. “RTP was not observed on the negotiated UDP ports from this capture point” is a network-path finding. “RTP was continuous, but no decoder configuration preceded an IDR in the observed window” is a codec-readiness finding. “The SDP payload type and the actual payload disagree” is a server metadata finding. Each statement tells the next owner what to test and prevents a player swap from erasing the original evidence.

Preserve the capture long enough to cover a clean reconnect. A reconnect that changes payload type, ports, or parameter sets is valuable evidence; a capture that starts after the failure may make the session look healthy because it has missed the broken setup. Redact credentials, retain the protocol fields, and record the camera profile and firmware only when those facts are known. That is enough for a vendor to reproduce the same control/media boundary without asking for a vague “no video” screenshot.

If packet capture cannot be enabled in production, collect the same boundaries from a controlled staging camera before changing the customer endpoint. A player debug log can supplement the case, but it must not replace the SDP, transport, and media observations that distinguish a network failure from a decode-readiness failure.

The minimum delivery packet is the sanitized SDP, negotiated transport, first expected RTP window, sequence continuity, timestamp progression, payload type, and observed codec parameter sets. Include one clean reconnect using the same camera profile. The RTSP troubleshooting workflow uses that evidence to distinguish no media, wrong media, and media that arrived but was not decode-ready.

Keep the reconnect capture with the original case.

Practical questions

What is the fastest reliable way to start?

Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.

What evidence should be saved?

Keep the input identity, application version, platform, relevant settings, exact action, first unexpected transition, and final output. If the workflow creates a project, session, report, or export, close and reopen it before treating it as durable evidence.

When should the procedure be repeated?

Repeat it after an application, operating-system, driver, firmware, model, source, or workflow change that can alter the result. Preserve the earlier accepted case so the comparison uses the same acceptance boundary rather than memory.

Related guides

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