Help

Connect to and Test an RTSP Stream

Direct answer

Enter a complete rtsp:// URL, put the username and password in the connection options, select TCP for the first test, and start analysis. A useful first run should show the control sequence from OPTIONS or DESCRIBE through SETUP and PLAY, followed by RTP or a precise failure boundary. The current application does not treat http://, https://, rtsps://, HLS, FLV, or WebRTC as a supported live RTSP input.

TCP interleaved analysis is part of the core Community path. UDP analysis is an advanced-network Professional capability. If UDP is locked, that is a license boundary, not evidence that the camera or RTSP URL is broken.

Build the RTSP URL

Use this structure:

rtsp://host:port/path

For example:

rtsp://192.168.1.100:554/stream1
rtsp://10.0.0.50:8554/live
rtsp://camera.local/Streaming/Channels/101

The host identifies the camera, encoder, NVR, proxy, or media server. Port 554 is common but not universal. The path is vendor and configuration specific; a reachable host with the wrong path can return 404 or non-SDP content.

Avoid embedding passwords in a copied URL. RTSP Inspector accepts credentials in the connection options and sanitizes retained request evidence. If credentials arrive in URL user information, the runtime extracts them and removes the password from the stored URL, but separate fields reduce accidental disclosure in tickets, screenshots, shell history, and documents.

URL check	Valid example	Failure it prevents
Scheme	`rtsp://`	Unsupported HTTP, HTTPS, or RTSPS input
Host	IP address or resolvable name	Empty or unreachable destination
Port	Actual RTSP listener	Connecting to the web administration port
Path	Exact stream resource	404, HTML, JSON, or wrong camera channel
Encoding	Reserved characters handled correctly	Malformed request target
Credentials	Connection-option fields	Password leakage in evidence

Record the connection context

Before testing, record the device model, firmware, stream profile, host operating system, network location, selected transport, and expected result. If another client works, record its exact URL, transport, and time rather than saying only “VLC works.” Different clients may use a different track URL, authentication retry, user agent, keepalive, or transport.

Saved profiles deliberately do not preserve passwords. Re-enter the password when needed and treat an empty password after profile selection as expected security behavior.

Choose TCP or UDP

TCP interleaved carries RTP and RTCP inside the RTSP TCP connection on negotiated interleaved channels. It is the best first test because it avoids separate inbound UDP media ports and usually crosses NAT, VPN, and firewall boundaries more predictably.

UDP negotiates client ports in SETUP and expects media datagrams on those ports. It can expose the deployment’s real UDP behavior, but requires Professional advanced-network capability and a network path that permits the negotiated traffic.

Result	Interpretation
TCP and UDP both work	Basic control and both media paths are available
TCP works, UDP receives nothing	Inspect firewall, NAT, VPN, VLAN, and port negotiation
Both fail before SETUP	Investigate reachability, URL, authentication, or DESCRIBE
UDP option is disabled	Check edition capability before diagnosing the camera

Do not use UDP first when the goal is to prove the URL and credentials. Establish the control plane over TCP, then run a separate UDP test without changing unrelated variables.

First test workflow

Confirm the camera and workstation clocks and record the test time.
Enter the sanitized RTSP URL.
Open connection options and enter username and password if required.
Keep TCP selected and use the default timeout unless the environment requires a documented change.
Start analysis once.
Watch for OPTIONS, DESCRIBE, SETUP, PLAY, and the first media evidence.
Stop after enough packets establish success or after the first repeatable failure.
Open Diagnostics before drawing conclusions from a single packet.
If the run matters, export JSON or use Professional case replay and reports.

Repeatedly clicking Analyze can create overlapping observations and make server limits look like the original fault. Finish or stop one run before starting another.

Validate each layer

Layer	Success evidence	Failure evidence
Name and route	Host resolves or IP is reachable	DNS, route, VPN, or address error
TCP listener	Connection to RTSP port succeeds	Refused, reset, or timeout
Authentication	Retry produces an accepted response	Repeated 401 or unsupported challenge
DESCRIBE	200 response with SDP	404, server error, HTML/JSON, malformed SDP
SETUP	Accepted transport and Session context	454, 461, bad control URL, port issue
PLAY	Accepted play state	Session, range, or server resource error
Media	RTP/RTCP arrives on negotiated path	No media, gaps, wrong payload, unstable SSRC

The application can retry supported Basic or Digest authentication using the supplied credentials. A 401 challenge is therefore not automatically the final failure; inspect whether the authenticated retry occurred and what the next response returned.

Common failures

Connection refused means the host actively rejected the chosen port or no service is listening. A timeout instead points toward routing, firewall, address, or an unresponsive endpoint.

401 Unauthorized requires checking username, password, account state, challenge method, realm, nonce behavior, and the authenticated retry. Do not publish a full Authorization value.

404 Not Found usually means the requested RTSP resource is absent, but also inspect aggregate and track control URLs derived from SDP. A DESCRIBE path can work while a later SETUP target fails.

DESCRIBE returns HTML or JSON means the request likely reached a management endpoint, proxy, or wrong service rather than a valid SDP resource.

PLAY succeeds but no media arrives requires transport-specific review. For UDP, confirm the client and server ports and network policy. For TCP, inspect negotiated interleaved channels and whether media frames arrive on them.

Use the complete RTSP troubleshooting guide for a layered investigation.

Connection QA

The input uses a supported rtsp:// scheme and a complete host.
Passwords are entered separately and excluded from notes and screenshots.
Port, path, camera profile, firmware, and test time are recorded.
TCP is tested before UDP unless the case specifically requires UDP.
Only one analysis run is active.
The last successful RTSP method and first failure are identified.
SDP and resolved track controls are retained where DESCRIBE succeeds.
Media conclusions match the negotiated transport.
Reports distinguish observed evidence from inferred cause.

FAQ

Does ONVIF discovery guarantee the RTSP URL works?

No. Discovery or device-management success does not prove the RTSP service, resource path, credentials, SDP controls, or media transport.

Can I test an RTSPS URL?

Not through the current live input. The launcher recognizes rtsps:// as unsupported rather than silently treating it as ordinary RTSP.

Why does another player work when this test fails?

Compare the exact URL, credentials, transport, user agent, authentication sequence, resolved track controls, and time. “Works elsewhere” is useful baseline evidence only when those variables are known.

Direct answer and acceptance boundary

For “Connect to and Test an RTSP Stream”, the short answer is: Connect RTSP Inspector to a camera, encoder, or NVR with a valid RTSP URL, separate credentials, TCP or UDP transport, and a verifiable first-test workflow. Treat that statement as a result to verify, not as a promise that every input, device, project, or environment behaves identically. A complete result records the starting state, the exact action, the visible output, and the condition that proves the task is finished in RTSP Inspector.

Evidence-first operating procedure

Work from a small, repeatable case before changing a full project. Record the application version, operating system, input or device identity, relevant settings, and the expected result. Perform one deliberate action, preserve the first unexpected transition, and compare it with a known-good run whenever one is available. Changing several controls at once may hide which condition fixed or created the problem.

Checkpoint 1: Connect to and Test an RTSP Stream

Treat “Connect to and Test an RTSP Stream” as a separate acceptance gate for “Connect to and Test an RTSP Stream”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 2: Connect RTSP Inspector to a camera, encoder, or NVR with a valid RTSP URL, separate creden

Verify “Connect RTSP Inspector to a camera, encoder, or NVR with a valid RTSP URL, separate credentials, TCP or UDP transport, and a verifiable first-test wor” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 3: Direct answer

For “Direct answer”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 4: Build the RTSP URL

Use “Build the RTSP URL” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Checkpoint 5: Record the connection context

When “Record the connection context” is ambiguous, compare one known-good case with one failing case under matching conditions. Mark the first meaningful difference rather than listing every later symptom. That first boundary usually produces a clearer support request and a safer next experiment.

Checkpoint 6: Choose TCP or UDP

Close “Choose TCP or UDP” only after the saved, exported, or reopened result still matches the observed state. Temporary UI feedback is useful, but durable evidence is stronger. Record any limitation that remains so the next reader does not interpret an incomplete path as a successful one.

Checkpoint 7: First test workflow

Treat “First test workflow” as a separate acceptance gate for “Connect to and Test an RTSP Stream”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 8: Validate each layer

Verify “Validate each layer” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 9: Common failures

For “Common failures”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 10: Connection QA

Use “Connection QA” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Acceptance matrix

Checkpoint	Evidence to retain	Pass condition
Connect to and Test an RTSP Stream	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Connect RTSP Inspector to a camera, encoder, or NVR with a valid RTSP URL, separate credentials, TCP or UDP transport, a	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Direct answer	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Build the RTSP URL	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Record the connection context	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Choose TCP or UDP	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome

Failure isolation, recovery, and handoff

If a check fails, stop at the first failed boundary. Preserve the source, project, session, or capture; duplicate it before destructive editing; and change one variable per experiment. Repeating a broad workflow after several simultaneous changes may produce a different result without explaining why.

Separate absence of evidence from evidence of absence. A blank view may mean the wrong input, scope, filter, permission, device, time range, or project state rather than “nothing happened.” Verify the acquisition or import path before interpreting a decoder, editor, report, or export.

Before handoff, reopen the durable artifact and inspect its beginning, the decision point, and its end. Record version, platform, relevant configuration, expected behavior, observed behavior, and the smallest reproduction. Remove or redact sensitive material and confirm the recipient is authorized to receive it.

Questions and answers

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.

When is the task ready for handoff?

It is ready when another authorized person can identify the input, repeat the action, see the same result, understand any remaining limitation, and open the saved artifact without relying on undocumented local state.

Related guides

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