RTSP Scale and Speed Header Debugging

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:

1. Capture the working normal-speed PLAY.
2. Capture the trick-play PLAY.
3. Compare Range, Scale, and Speed headers.
4. Check response status code.
5. Check response headers for accepted rate.
6. Compare RTP timestamp cadence.
7. Check whether audio stops intentionally.
8. Look for keyframe-only video behavior.
9. Test supported discrete speeds.
10. 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.