2026-06-02

RTSP Range Header and npt=now: Debugging Live Playback Start Time, Resume, and Camera Seek Errors

How to troubleshoot RTSP Range headers, npt=now, live camera playback, resume behavior, wrong start time, invalid seek, PLAY requests, and server response timing.

A stream can connect yet start late, resume from the wrong point, or fail only when PLAY carries an RTSP Range such as npt=now-. Compare the requested start position with the server's Range/RTP-Info response and the first RTP timestamps to determine whether the client asked for an unsupported seek or the server mapped live time incorrectly. This evidence ties control-plane playback timing to the media start; it does not make RTP timestamps equivalent to wall-clock or recorder-file time.

The Range header is a control-layer timing instruction. It is not the same as RTP timestamp, wall-clock time, or recorder file timestamp. RTSP Inspector is useful because this problem sits in the RTSP method sequence and must be compared with RTP/RTCP media timing after PLAY.

What Range means in RTSP

During PLAY, a client can send:

PLAY rtsp://camera/stream RTSP/1.0
Session: 12345678
Range: npt=now-

For a live stream, npt=now- usually means "start playing from the current live point." Some clients omit the Range header. Some send npt=0.000-. Some NVRs use clock-based ranges for recorded playback.

Different RTSP servers vary in how strictly they interpret these values.

Live stream vs recorded stream

Live streams and recorded streams have different expectations:

Live camera stream: current live media point.
NVR playback: requested recording time range.
Media file: offset into stored content.
Replay server: session-specific timeline.

A Range value that is valid for a file may be invalid for a live camera. A Range value that works for one NVR may not work for another vendor.

Common symptoms

Range-related problems include:

PLAY fails only when Range is present.
Stream starts but with long delay.
Resume after pause fails.
Client receives old buffered video.
NVR playback starts at wrong time.
RTP timestamps jump after resume.
Camera ignores Range but returns 200 OK.
Server returns invalid Range response.

The player may show this as buffering or black video, but the root evidence is in PLAY.

Server response matters

After PLAY, the server may return a Range header:

RTSP/1.0 200 OK
Range: npt=0.000-
RTP-Info: url=...;seq=...;rtptime=...

RTP-Info can map the control response to initial RTP sequence and timestamp values. If RTP-Info is missing, wrong, or inconsistent, clients may struggle to align media timing.

Inspect:

Range sent by client.
Range returned by server.
RTP-Info sequence and rtptime.
First RTP sequence after PLAY.
First RTP timestamp after PLAY.

Pause and resume

Some cameras support PAUSE; others do not support it well for live streams. A client may pause and later send PLAY with a Range value that the server treats as a seek. The server may reject it or restart the stream.

If resume breaks, compare the first PLAY with the resume PLAY.

Debug checklist

Use this process:

Capture PLAY request and response.
Check whether client sends Range.
Record exact value: npt=now-, npt=0-, clock range, or absent.
Check server response Range and RTP-Info.
Compare first RTP sequence/timestamp after PLAY.
Test with and without Range if the client allows it.
Test live stream and recorded playback separately.
Check pause/resume method sequence.
Avoid blaming RTP until PLAY timing is understood.
Preserve the whole RTSP control flow for vendor diagnosis.

Build a playback-timing evidence table

Treat every PLAY as a before-and-after boundary. The control request describes what the client asked to play; the response describes what the server says it will play; the first media packets show whether that promise became observable. Putting those three facts on one line prevents a common support mistake: calling an old buffered frame a seek failure without checking the returned Range or RTP-Info values.

Evidence boundary	What to record	What a mismatch can mean
Client `PLAY`	Session, requested `Range`, transport, and request time	The client may be sending file-style or resume semantics to a live source
Server response	Status, returned `Range`, `RTP-Info`, and any warning	The server may ignore, clamp, or reject the requested start point
First RTP after `PLAY`	Payload type, sequence, timestamp, and arrival delay	Media may be delayed, mapped to another track, or absent despite control success
Resume `PLAY`	Difference from the first request and response	Pause/resume behavior may turn into an unsupported seek
RTCP sender report	RTP-to-clock mapping when available	It can explain timeline correlation, but does not rewrite the requested RTSP Range

A live camera cannot necessarily seek to an absolute history point. npt=now- is usually a request for the current presentation point, but implementations differ: one server may return npt=0-, another may omit Range, and another may return 457 Invalid Range. None of those results should be guessed from the player UI. Record the literal header values and whether the server continued to send RTP. If it did, check that the first packet sequence and rtptime agree with the response closely enough for the client to initialize its pipeline.

For recorded playback, separate three clocks: the requested record-time range, the server's presentation timeline, and RTP's media clock. A camera may expose recorded video through a URL that looks like a live stream, while an NVR may use UTC-style clock ranges that a generic player never sends. The diagnostic question is therefore not “does this URL support Range?” but “which Range syntax and timeline does this endpoint advertise, echo, and actually honor?” Capture a working and failing request pair before changing the client.

A repeatable comparison experiment

Start a clean live session and save the complete OPTIONS through PLAY exchange.
Repeat with the client’s default Range behavior, then with Range omitted if the tool permits it.
For each attempt, measure control response time and first RTP arrival time.
Record the returned Range and RTP-Info rather than copying only the status code.
Pause and resume once, then compare that second PLAY side by side with the initial PLAY.
If the endpoint supports recorded playback, repeat against one known recording interval; do not infer recorder behavior from the live test.

Why does 200 OK still show the wrong frame? A successful RTSP response only means the server accepted the method. It may clamp the Range, resume a cached presentation point, or start media later than the requested point. The returned headers and first media packets decide whether the visible frame is consistent with the control exchange.

Should RTP timestamp be converted to wall-clock time? Only when the stream provides the necessary RTCP mapping and the capture preserves it. RTP timestamps advance at the codec clock rate; they are not wall-clock timestamps by default. For deeper timing cases, pair this trace with the RTP timestamp drift guide and use the RTSP troubleshooting workflow to retain the control and media evidence together.

Keep the endpoint identity fixed while testing

Range bugs are easy to misdiagnose when a load-balanced camera gateway, NVR, or proxy sends consecutive attempts to different backends. Record the RTSP URL, server header if exposed, session value, selected track control URL, transport, and time of each test. A live test that works once and fails once may be a backend consistency issue rather than a client parsing issue. Compare the returned Range and RTP-Info values across attempts before changing the request syntax.

If authentication, redirects, or session cleanup are also involved, keep them outside the Range conclusion. A 401, a stale session, or a transport setup failure can prevent PLAY from reaching the timing behavior at all. Conversely, when PLAY is consistently accepted and media begins at an unexpected point, avoid adding unrelated credentials or decoder theories to the report. State the smallest reproducible sequence, the expected start semantics, the observed response, and the first media evidence.

This distinction helps a camera vendor reproduce the case quickly: they can issue the same request with the same Range, observe their server's response, and compare the first sequence/timestamp pair without reverse-engineering a player UI. It also gives an integration team a safe workaround boundary—omit Range for one live endpoint only when the captured evidence shows that omission restores correct live behavior.

For repeat tests, keep the requested URI byte-for-byte identical except for the Range value under investigation. Some cameras expose different main/sub-stream or recorded/live behavior through adjacent paths, and a changed URL can create a false impression that the Range header fixed the problem. Note the selected track control URL from SDP as well: a server may accept a session-level PLAY but map timing differently for aggregate versus track-specific control. The final report should name endpoint class, Range syntax, returned Range, media start, and one successful comparison so an implementation team can reproduce it.

Keep the original response headers in the case file. A copied status code loses the Range and RTP-Info fields that make a playback-timing conclusion testable. Keep the matching request headers beside them, because a server response without its triggering request cannot establish whether the client asked for live or recorded semantics.

Final diagnosis

RTSP Range problems are playback-control timing problems. The stream may authenticate and set up correctly, but PLAY can still start from the wrong point or fail because the server does not accept the requested range.

RTSP Inspector helps by showing Range, RTP-Info, and the first RTP packets together, so live playback start-time issues can be diagnosed from protocol evidence.

How should a live Range fix be verified?

Run PLAY without Range, with the client’s original Range, and with the server-supported live form while keeping session and transport comparable. For each run record response status, returned Range, RTP-Info sequence/timestamp, first observed RTP sequence/timestamp, and startup delay. A successful 200 response is not enough if the media begins at an impossible timeline or never matches RTP-Info. Preserve the three runs as the acceptance table.

Repeat once after a fresh SETUP to exclude stale session state.

Record the result.

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.

Related guides

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