RTSP Main Stream Not Working but Sub Stream Works: What the Difference Proves

A very common IP camera search query is "RTSP main stream not working but sub stream works." The symptom is specific enough to be useful. If the sub stream works, the camera is reachable, credentials are probably correct, RTSP service is enabled, and at least one video profile is accessible. The problem is no longer "RTSP is broken." The problem is the difference between stream profiles.

Main stream and sub stream usually differ in resolution, bitrate, codec, GOP interval, payload size, and sometimes even URL path. A sub stream may be H.264 at low resolution while the main stream is H.265, 4K, high bitrate, or restricted to fewer concurrent sessions. An NVR can expose different paths from the camera itself. ONVIF may return a low-quality live URL while the recording URL or main profile requires a separate path.

The useful diagnostic question is: what does the working sub stream prove, and what does it not prove?

What a Working Sub Stream Proves

If the sub stream can be opened over RTSP, you can usually say:

• the camera IP address is reachable
• the RTSP port is open
• authentication works for at least one stream
• the client can parse basic RTSP responses
• DESCRIBE, SETUP, and PLAY can succeed for at least one profile
• RTP delivery is possible for at least one media track

That is valuable evidence. It narrows the search. You should not keep debugging basic network reachability after this point unless the main stream uses a different host, port, transport mode, or NVR path.

What a Working Sub Stream Does Not Prove

A working sub stream does not prove:

• the main stream URL path is correct
• the main stream is enabled
• the main stream codec is supported
• the main stream bitrate can cross the network
• the main stream is available to multiple clients
• the main stream sends decode-ready SPS/PPS or VPS/SPS/PPS evidence
• the NVR exposes the camera main stream through the same path

This is why "VLC can open the sub stream" is not enough for a VMS, analytics system, or restreaming pipeline that needs the main stream.

Check URL Path Before Codec

Many camera families use different path patterns for main and sub streams. Some use profile1 and profile2. Some use /Streaming/Channels/101 and /Streaming/Channels/102. Some use main, sub, video1, video2, or vendor-specific access names. Some NVRs expose channels differently from direct camera URLs.

If the main stream returns 404 Not Found, inspect:

• exact request URI sent in DESCRIBE
• whether the URL path matches the vendor model
• channel number
• stream number
• profile token discovered by ONVIF
• whether the stream is enabled in the camera web UI
• whether the URL targets camera IP or NVR IP

Do not treat a 404 as packet loss. RTP has not started yet.

Check Codec and Bitrate After the Path Is Valid

If the main stream returns SDP and starts RTP but still does not show video, move to codec and media evidence.

Main stream failures often come from:

• H.265 selected while the consumer expects H.264
• missing H.264 SPS/PPS or H.265 VPS/SPS/PPS evidence
• very long key-frame interval
• high bitrate loss over Wi-Fi or weak uplink
• packet fragmentation and loss under motion
• decoder profile or level unsupported by the downstream system

At this stage, the report should include SDP, payload type, RTP sequence continuity, codec NAL unit evidence, and whether the first decode boundary was reached.

Concurrency Limits and NVR Behavior

Some budget DVRs, NVRs, or camera firmware builds limit main stream access. The sub stream may stay available while the main stream is already consumed by local display, recording, vendor app, or another client. This can look like a URL problem even when the path is correct.

Useful checks:

• disconnect other viewers
• test direct camera IP versus NVR IP
• compare main stream from camera web UI
• lower main stream bitrate or resolution
• switch main stream codec from H.265 to H.264
• test RTSP over TCP interleaved and UDP separately

If lowering bitrate fixes the issue, the original failure may be transport capacity rather than URL syntax.

How RtspInspector Should Frame This Case

RtspInspector is strongest when it explains the boundary:

• sub stream control path succeeds
• main stream control path fails with status code
• main stream returns SDP but no RTP
• main stream RTP arrives with packet loss
• main stream codec metadata is missing or unsupported
• main stream is H.265 while consumer needs H.264

That is the difference between "main stream broken" and a useful support report. The correct next action might be vendor URL lookup, stream profile configuration, codec change, bitrate reduction, firmware update, or network path repair.

If your exact search is "RTSP sub stream works but main stream does not," start by comparing RTSP methods, SDP, codec, transport, and concurrency. The working sub stream is not the end of the diagnosis. It is the control sample.