2026-06-02

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

A diagnostic guide for IP camera cases where the RTSP sub stream works but the main stream fails, freezes, returns 404, or cannot be decoded.

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 RTSP Inspector Should Frame This Case

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

Compare the two profiles as two separate sessions

Do not compare only the final image. Capture the main and sub stream from a fresh client under the same authorized conditions, then place their RTSP and SDP facts side by side. The sub stream is a useful control, but it is not an interchangeable version of the main profile.

Session fact	Sub stream result	Main stream result	Why the difference matters
`DESCRIBE` status			Distinguishes URL/profile access from media delivery
SDP codec and payload type			Identifies H.264/H.265 or mapping difference
Resolution/bitrate/profile			Reveals capacity or decoder requirement change
`SETUP` transport			Finds UDP/TCP or track-specific negotiation difference
First RTP/RTCP time			Separates no-media from late/blocked media
First IDR/decode-ready boundary			Explains fresh-decoder black screen
Concurrent viewer count			Tests profile-specific resource limits

Leave the values blank in a template until they are observed; do not copy vendor URL patterns into a production case and call them verified. This table gives the camera administrator, VMS team, and network owner one shared vocabulary.

Use RTSP method boundaries to choose the right branch

The first differing method narrows the search dramatically. A 404 at DESCRIBE is a resource/profile path problem. A successful SDP followed by a failed SETUP points to track control URL, transport, or per-track policy. A successful PLAY with no usable frame is a media/codec/delivery branch.

First main-stream difference	Meaning at the observed boundary	Next evidence
401 on `DESCRIBE`	Account/path access differs from sub stream	Current auth challenge and profile permission
404 on `DESCRIBE`	Server reached but resource/profile path not exposed	Sanitized URI, channel/profile state, direct vs NVR target
461 at `SETUP`	Proposed transport not accepted	Transport header, server reply, UDP/TCP comparison
503 at `SETUP` or `PLAY`	Resource/capacity policy may be limiting stream	Concurrent sessions, recovery window, device logs
SDP and RTP arrive but decoder fails	Codec configuration or delivery may differ	Payload mapping, SPS/PPS or VPS/SPS/PPS, sequence run
RTP absent after successful PLAY	Media route or server output may be missing	Port/channel mapping, firewall/NAT, camera counters

Use the RTSP 461 unsupported transport guide for transport refusal and the RTSP 503 camera resource-limit guide for capacity evidence. They are distinct cases even if the user sees only a black main stream.

Evaluate codec and startup readiness without guessing

Main streams are frequently H.265 while sub streams remain H.264. They can also use a higher H.264 profile, longer key-frame interval, or larger fragmented packets. A client that is valid for the sub stream may lack a decoder or buffer policy for the main stream. State exactly what SDP and RTP prove.

Main-profile observation	Evidence-compatible explanation	Controlled comparison
H.265 main / H.264 sub	Consumer may not support main codec	Test an authorized H.264 main profile, keeping client/path fixed
Main profile has long startup delay	Join may occur mid-GOP or wait for IDR	Measure first IDR and first decoded frame
Parameter sets missing at fresh start	Decoder configuration boundary is incomplete	Inspect SDP and in-band configuration NALs
Higher bitrate correlates with gaps	Capacity/delivery may be stressed	Compare permitted wired/UDP/TCP path one variable at a time
Same codec but different payload mapping	SDP/client mapping may differ by profile	Parse each session's `rtpmap`/`fmtp` independently

The missing H.264 SPS/PPS decoder guide applies when H.264 configuration is incomplete. For H.265, retain VPS/SPS/PPS evidence and do not call an H.265 stream corrupt merely because an H.264-only client cannot decode it.

Test capacity and concurrency safely

The main profile can consume an encoder session, camera CPU, NVR restream slot, or network bandwidth that the sub profile does not. Do not simulate a denial of service by opening many clients. Use a maintenance window, a test camera, or one controlled viewer change.

Capture a baseline sub/main comparison with other viewers documented.
Disconnect one known permitted viewer and retest the main profile.
Compare direct camera and NVR paths only if both are authorized.
Keep credentials, profile, and client constant while changing one transport/path variable.
Measure status, first RTP, sequence continuity, and decoder readiness—not only whether a player eventually shows an image.
Restore the original environment and report the smallest reproducible difference.

QA case	Acceptance evidence
Profile access	Correct DESCRIBE path/status for both profiles
Codec comparison	SDP mapping and supported-decoder boundary recorded
Transport test	UDP/TCP difference is labelled transport-specific
Capacity test	Concurrent viewer state and repeatable response captured
Startup test	First key frame/configuration/decoded-frame timing retained
NVR boundary	Direct and proxy streams are never mixed in one conclusion

Questions about a working sub stream and failed main stream

Does the working sub stream prove credentials and network are fine?

It proves they work for that sub-stream session. The main profile can have different access rights, URL path, codec, transport behavior, capacity, and bitrate, so it does not eliminate those branches.

Should I lower main-stream resolution or bitrate immediately?

Only as an authorized controlled comparison. A change that makes the stream work is evidence about the profile/path, but it does not by itself identify whether encoder load, network capacity, packetization, or decoder support was the limiting factor.

Why does the main stream work through the camera UI but not the NVR?

The UI and NVR may use different transports, profiles, restreaming boundaries, permissions, or decoder paths. Compare the exact RTSP/SDP evidence at each boundary instead of assuming they request the same resource.

What can RTSP Inspector prove here?

It can show the first protocol/media difference between two profiles: status code, SDP, transport, RTP/RTCP arrival, payload mapping, sequence condition, and codec readiness. It cannot prove a hidden camera resource allocation without device-side logs.

The practical conclusion should say what the sub stream controlled for and what the main stream changed. That turns “one works and one does not” into a short, testable handoff.

Record the two DESCRIBE responses, selected media control URLs, transport, codec, resolution, and first RTP arrival side by side. The RTSP troubleshooting guide can then assign the next test to profile configuration, bandwidth, codec readiness, or server resource limits instead of treating both profiles as equivalent.

Related guides

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