2026-06-03

RTSP Scale Header: Fix NVR Trick Play

How to debug RTSP Scale and Speed headers, fast forward, slow motion, NVR playback, Range interactions, unsupported playback rate, and trick play camera behavior.

For “RTSP Scale Header: Fix NVR Trick Play”, the short answer is: How to debug RTSP Scale and Speed headers, fast forward, slow motion, NVR playback, Range interactions, unsupported playback rate, and trick play camera behavior. 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.

Recorded RTSP playback may run normally at 1× yet reject fast-forward, reverse, or slow motion with an unsupported-rate error. Diagnose that NVR trick-play failure by comparing the client's PLAY request—especially Scale, Speed, and Range—with the server response and the RTP timeline that follows. Control-plane evidence can show whether the server rejected, clamped, or ignored the RTSP Scale/Speed header; it cannot promise that a camera or recorder implements every requested playback rate. RTSP Inspector is useful because trick play is a control-plane problem. The client sends PLAY with Range, Scale, or Speed, and the server may accept, clamp, ignore, or reject the request.

Scale vs normal playback

Normal playback often looks like:

PLAY rtsp://nvr/recording RTSP/1.0
Range: npt=0-

Trick play may add:

Scale: 2.0

or another rate depending on server support. Some servers only support selected values. Some ignore unsupported values. Some return a response header with the actual accepted scale.

Common symptoms

Failures appear as:

Fast forward button does nothing.
Stream jumps to wrong time.
Playback freezes after Scale request.
Server returns 455 Method Not Valid in This State.
Server returns 457 Invalid Range.
Server returns 501 Not Implemented.
Server accepts PLAY but keeps normal speed.
NVR sends only keyframes during fast forward.
Audio disappears during trick play.

These are not the same failure. The exact request and response headers matter.

Range interaction

Recorded RTSP playback often combines Range with Scale.

Examples:

Range: npt=120-
Scale: 4.0

or:

Range: clock=20260603T010000Z-
Scale: 0.5

If the client sends a time format the server does not support, the failure may look like a speed problem even though Range is the real issue.

Server clamps or rewrites speed

Some NVRs accept only discrete values:

0.5
1.0
2.0
4.0
8.0
keyframe-only modes

If the client requests 3.0, the server may choose 2.0 or 4.0. A good trace compares requested rate with accepted response headers and actual RTP timing.

Audio behavior during trick play

Many servers drop audio during fast forward or reverse playback. This may be expected because audio cannot be meaningfully decoded at high speed.

Evidence:

Video SETUP remains active.
Audio RTP stops after fast-forward PLAY.
Server sends RTCP BYE for audio.
Audio track resumes when Scale returns to 1.0.
SDP still advertises audio, but playback mode suppresses it.

Do not diagnose this as packet loss until the RTSP control state is checked.

Keyframe-only fast forward

NVRs often send only keyframes during high-speed playback. That reduces bandwidth and decoding access but changes RTP cadence.

Symptoms:

Video appears jumpy.
RTP bitrate drops.
Frames are sparse.
Marker bit cadence changes.
Timestamps jump by large intervals.

This can be correct trick-play behavior, not stream corruption.

Unsupported reverse playback

Reverse playback is not universally supported. Some servers reject negative scale values. Others emulate reverse playback by jumping between keyframes.

Search terms:

"RTSP reverse playback not supported"
"RTSP negative Scale"
"NVR rewind RTSP"
"RTSP trick play only keyframes"

The diagnostic question is whether the server explicitly rejected the requested rate or silently changed behavior.

Debug checklist

Use this process:

Capture the working normal-speed PLAY.
Capture the trick-play PLAY.
Compare Range, Scale, and Speed headers.
Check response status code.
Check response headers for accepted rate.
Compare RTP timestamp cadence.
Check whether audio stops intentionally.
Look for keyframe-only video behavior.
Test supported discrete speeds.
Preserve request and response headers for NVR vendor support.

Final diagnosis

RTSP fast forward, slow motion, and trick play failures should be diagnosed from control headers and media timing together. The server may reject, clamp, ignore, or partially support Scale and Speed.

RTSP Inspector helps prove whether the issue is unsupported playback rate, Range format, NVR trick-play policy, audio suppression, or client interpretation.

Make normal and trick-play requests comparable

Treat normal playback as the control case. Capture a complete PLAY request at scale 1.0, then repeat the same recording position with one rate change. If the client also changes the Range syntax, transport, track selection, or connection at the same time, a rejected request cannot be assigned honestly to Scale or Speed. Keep CSeq, URL, Session header, Range, Scale, Speed, and response status together for both attempts.

Request outcome	Evidence to compare	Likely meaning	Next step
1.0 succeeds, 2.0 gets 501	PLAY response and requested rate	Server does not implement that trick-play behavior	Test documented discrete rates; retain rejection
1.0 succeeds, 2.0 gets 457	Range format and playback window	Range or recording boundary may be invalid	Retry the same range at 1.0 before blaming Scale
2.0 returns 200 but media remains 1.0	Response headers and RTP cadence	Server ignored or clamped the requested rate	Compare accepted rate and timestamps
4.0 yields sparse video only	RTP marker/timestamp cadence and key frames	Keyframe-only fast forward may be intentional	Verify the NVR mode, not packet loss first
Video works but audio stops	Track state and RTCP BYE or silence	Audio suppression may be a trick-play policy	Return to 1.0 and confirm audio resumes

The useful result is a statement such as “the recorder accepted PLAY but clamped Scale 3.0 to its 2.0 policy” or “the same Range is invalid regardless of rate.” A button that appears unresponsive does not provide that distinction.

Separate Range errors from speed errors

Recorded RTSP servers can accept one Range syntax and reject another. npt=120- and a clock-based range answer different questions: one is relative playback position and the other is a wall-clock recording window. Before changing the rate, confirm that normal playback accepts the exact Range requested for trick play. Then modify one header at a time.

When an NVR returns 457 Invalid Range, record whether it reports a valid start/end window, whether the recording actually exists at that time, and whether the response arrives before any media starts. A valid Scale value cannot repair a nonexistent archive segment. Similarly, a playback request at a supported clock range can still reject reverse or fractional scale because that is a separate server capability.

If a case is about a live stream rather than a recording, state that explicitly. Many cameras offer normal live PLAY but have no meaningful archive timeline or reverse-playback model. Calling the result “RTSP Scale broken” in that situation conceals a product capability boundary.

Read response headers and media timing together

Some servers acknowledge the requested Scale; some include the selected value in a response; others say nothing and reveal the actual behavior only in timestamps and frame cadence. Keep the response body and headers, but do not stop there. Observe a bounded RTP interval after PLAY: packet count, marker cadence, timestamp progression, sequence continuity, and which tracks remain active.

At high rate, video can become intentionally discontinuous while still valid for trick play. A recorder may deliver I-frames only, skip audio, and jump timestamp ranges. This differs from packet loss: packet loss leaves missing sequence evidence or RTCP symptoms inside an otherwise expected cadence. Use the RTCP sender report and jitter guide only after the control exchange establishes what cadence the NVR intended to send.

Reverse playback deserves special care. A negative or reverse-style request can be unsupported, implemented as keyframe seeks, or accepted only over a restricted archive window. Record the actual server response rather than inferring reverse support from a UI rewind icon.

Test an NVR rate policy without guessing

Run a small rate matrix against one known recording interval: 0.5, 1.0, 2.0, 4.0, and one unsupported value such as 3.0. Do not use the matrix to hammer a production recorder; use a short, controlled interval and close each session cleanly. For each row, retain the requested Range and Scale, response status, returned Scale or Speed if any, audio behavior, and a short media observation.

Test row	Why it is useful
0.5	Detects slow-motion support separately from fast forward
1.0	Establishes that the selected archive range and session work
2.0	Tests a common discrete fast-forward value
4.0	Shows whether keyframe-only or audio suppression begins at higher rate
3.0	Reveals clamping or explicit unsupported-rate behavior

The resulting table is more useful to a vendor than a request to “support fast forward.” It identifies which values the server accepts, which it changes, and whether media differs after acceptance.

Session and state pitfalls during playback control

Trick-play requests still belong to an RTSP session. If a Scale request follows a reconnect with a stale Session ID, a 454 response is a session-state problem before it is a rate problem. If PLAY is sent to the wrong aggregate URL, the server can reject the request even though the rate is supported. Preserve the sequence from SETUP to PLAY and use the RTSP 454 Session Not Found workflow or aggregate control URL guide when those signatures appear.

This ordering also protects against misleading successes. A new session that returns to 1.0 has not proved that the old session supported Scale; it may simply have repaired the session state.

RTSP Scale and Speed FAQ

Are Scale and Speed interchangeable?

Not universally. Camera and NVR implementations vary in which headers they accept, how they prioritize them, and which values they support. Capture exactly what the client sends and what the server returns; do not assume a header used by one product has identical semantics in another.

Why is audio missing only during fast forward?

Many trick-play implementations suppress audio because decoded sound at high or reverse speed is not useful. Confirm that audio RTP stops or is intentionally excluded after the high-rate PLAY and resumes at 1.0 before treating it as a network defect.

My NVR returns 200 but playback is still normal speed. Is that a bug?

It may have ignored the request or clamped it to a supported policy. Compare response headers and RTP timing with normal playback. A 200 alone proves only that the server accepted the RTSP method, not that it honored every optional playback preference.

What should go into a vendor ticket?

Include a redacted normal-speed and trick-play PLAY pair, the recording Range, requested Scale or Speed, response headers/status, session context, and a short description of observed video and audio behavior. Do not include camera passwords or private recording URLs.

What should I avoid inferring from a single fast-forward test?

Do not infer that a recorder has reverse-playback support because it accepts one positive Scale, that a missing audio track is permanent because it disappears at 4.0, or that a 200 response means the requested rate was honored. Repeat the same archive window at 1.0, then compare one controlled rate change. This small discipline keeps a trick-play ticket focused on an observable contract rather than a UI expectation.

Related guides

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