2026-06-02

RTP SSRC Change Mid-Stream: Camera Restarts, Sequence Resets, and Decoder Glitches

How to diagnose RTP SSRC changes in RTSP camera streams, sequence number resets, timestamp discontinuity, camera encoder restarts, failover streams, and decoder glitches.

RTP SSRC identifies the synchronization source of an RTP stream. When it changes in the middle of an RTSP session, users may see freezes, black frames, audio/video desync, corrupted video, packet-loss alarms, or sudden decoder reset. Search phrases include "RTP SSRC changed", "RTSP stream freezes after camera restart", "RTP sequence number reset", "RTP timestamp discontinuity", and "camera stream source changed mid stream".

RTSP Inspector is useful because this is not a normal player question. The key evidence lives in RTP packet headers, RTCP sender reports, SDP track metadata, sequence numbers, and timestamps.

What SSRC means

In RTP, each media source has an SSRC value. A video track and an audio track usually have different SSRC values. The receiver uses SSRC together with payload type, sequence number, timestamp, and RTCP reports to maintain stream continuity.

If the SSRC changes, a receiver must decide whether this is:

A legitimate new synchronization source.
A camera encoder restart.
A failover to another encoder.
A firmware bug.
A NAT/proxy rewrite issue.
A new stream incorrectly mixed into the same session.

Treating all SSRC changes as packet loss is misleading.

Common symptoms

An SSRC change can produce several visible symptoms:

Video freezes for a few seconds.
Decoder shows "invalid NAL unit" or "missing reference frame".
Playback continues but latency jumps.
Audio and video drift apart.
The client logs sudden packet loss.
RTCP jitter spikes.
Sequence numbers restart from a small value.
RTP timestamp jumps backward or forward.

The important question is whether the media identity changed at the same time as sequence and timestamp continuity.

Camera restart or encoder restart

Many IP cameras restart their encoder pipeline without closing the RTSP TCP connection. The control session may still look alive, but RTP changes underneath it.

Evidence:

Same RTSP session ID continues.
RTP SSRC changes.
RTP sequence number restarts.
RTP timestamp restarts or jumps.
RTCP sender report changes mapping.
Keyframe appears soon after restart, or decoder waits until next IDR frame.

If the stream recovers after the next keyframe, the issue may be encoder restart rather than network packet loss.

Failover and load-balanced media sources

Some systems relay RTSP streams through a gateway. If the gateway switches upstream cameras, recording pipelines, or transcoder workers, the receiver may see a new SSRC.

This can happen with:

NVR restreaming.
Cloud camera bridges.
RTSP proxy failover.
Multi-encoder camera firmware.
Redundant stream servers.
Load balancers that do not preserve media affinity.

If SSRC changes correlate with backend failover, the fix may belong in the relay layer.

Sequence number reset

RTP sequence numbers are 16-bit and normally increase by one for each packet in the same stream. A reset at the same moment as SSRC change may be expected. A reset without SSRC change is more suspicious.

Useful comparisons:

Old SSRC sequence range.
New SSRC first sequence number.
Payload type before and after.
Timestamp before and after.
Marker bit behavior near the boundary.
Whether a keyframe appears after reset.

This distinction matters because many people report "RTP sequence number reset" and assume packet loss, while the real cause is source replacement.

Timestamp discontinuity

RTP timestamps follow the media clock. For video this is often 90 kHz. If the timestamp jumps backward, a receiver may drop frames or reorder incorrectly. If it jumps far forward, jitter buffer behavior may change.

When SSRC changes, timestamp discontinuity can be acceptable if the receiver treats it as a new source. When SSRC does not change, timestamp discontinuity often points to a broken sender clock.

RTSP Inspector should show the timestamp boundary clearly:

old SSRC: sequence 43120, timestamp 88210000
new SSRC: sequence 210, timestamp 3000

That kind of evidence is more useful than a player screenshot.

RTCP sender report changes

RTCP sender reports map RTP timestamps to wall-clock time. If SSRC changes, the receiver should watch for new RTCP sender reports.

Questions to answer:

Does the new SSRC send RTCP SR?
Does the old SSRC send RTCP BYE?
Does the camera announce source shutdown?
Is jitter calculated per SSRC or across the boundary?
Does packet loss accounting reset correctly?

If a tool merges statistics across SSRC changes, it may show false loss, false jitter, or false bitrate dips.

Decoder behavior

Even when RTP is valid, decoders need a clean frame boundary. For H.264 and H.265, recovery may require SPS/PPS/VPS and an IDR frame.

After an SSRC change, check:

Does the next access unit include a keyframe?
Are SPS and PPS repeated?
Does the SDP still match the actual stream?
Does payload type stay the same?
Does fragmentation restart in the middle of a frame?

If the new source starts with P-frames only, the receiver may show black video until the next keyframe.

Debug checklist

Use this workflow:

Identify all SSRC values per RTP track.
Locate the exact packet where SSRC changes.
Compare sequence numbers before and after.
Compare RTP timestamps before and after.
Check RTCP BYE and sender reports.
Check whether RTSP session ID changed.
Check whether payload type changed.
Look for keyframe or codec config after the boundary.
Separate source restart from network loss.
Export the boundary packets for firmware or gateway debugging.

Final diagnosis

An RTP SSRC change is not automatically a network problem. It can reveal camera encoder restart, RTSP relay failover, timestamp reset, media source replacement, or decoder recovery delay.

RTSP Inspector helps by showing the media evidence that players hide: SSRC, sequence number, timestamp, RTCP behavior, keyframe recovery, and the exact packet where the stream identity changed.

Isolate the source-change boundary

Make a timeline around the first packet with the new SSRC. Keep the preceding and following RTP packets, RTCP packets, RTSP control messages, and arrival times. Group statistics by SSRC instead of summing across the boundary. A sequence reset with a new SSRC can be a legitimate new source; the same reset with an unchanged SSRC is a much stronger sender-continuity concern.

Boundary observation	What it proves	Next comparison
New SSRC and new small sequence value	A new RTP source identity appeared	Look for RTCP SR/BYE and encoder/failover event
Same SSRC, sequence drops backward	Sender continuity is irregular	Check restart, packet rewrite, or firmware behavior
New SSRC after RTSP reconnect	New session/source may be expected	Compare session ID and `SETUP` timing
New SSRC with no control-session change	Media path changed beneath a live session	Camera encoder, NVR relay, or upstream failover
SSRC change followed by IDR/keyframe	Decoder recovery has a defined starting point	Measure recovery time and codec configuration

Record payload type, timestamp, marker bit, source/destination tuple, and the first decodable frame as well. This avoids falsely reporting every old-to-new packet gap as network loss. For basic session evidence, use the RTSP Inspector connection guide and keep the troubleshooting report with the case.

Compare RTCP, codec state, and receiver recovery

An RTP source switch is most useful when paired with RTCP. The old source may send BYE, and the new one should eventually establish its own sender-report mapping. If the camera starts with predicted frames only, a receiver can have valid RTP yet continue to show black video until an IDR/keyframe and codec parameter sets appear.

Evidence after SSRC change	Bounded diagnosis
Old `BYE`, new SR, clean keyframe	Managed source/encoder transition is plausible
New SSRC, no SR, timestamp reset	Receiver timing must be treated as a new source; investigate sender behavior
Same payload type and SDP, keyframe delayed	Decoder recovery delay rather than login failure
Payload type or codec parameters change	Relay/profile change needs explicit compatibility review
No source change, only sequence gaps	Use packet-loss analysis instead of SSRC failover diagnosis

If packet loss is the observed problem, use RTP sequence-number wraparound and loss analysis. If media timing stays wrong after the source changes, compare RTP timestamp drift and clock rate. These are adjacent, but not interchangeable, diagnoses.

FAQ: RTP SSRC changed mid-stream

Does an SSRC change always mean a camera restart?

No. It can represent a camera encoder restart, NVR/proxy failover, a new upstream source, or a media rewrite. The RTSP session, RTCP events, source tuple, and configuration evidence determine which is plausible.

Should the receiver discard the new source?

Not automatically. The receiver should treat it as a new synchronization source and recover on valid codec boundaries. Whether a switch is allowed is a product/session policy decision.

Why does video remain black after the new SSRC arrives?

RTP packets can be valid while the decoder lacks an IDR frame, SPS/PPS/VPS, or a compatible payload configuration. Preserve the first access units after the change.

Escalation record

Send old/new SSRC values, exact boundary time, sequence/timestamp samples, payload type, RTCP SR/BYE evidence, RTSP session state, keyframe/configuration evidence, capture tuple, and whether a camera/NVR failover event was expected. Open RTSP Inspector with a short boundary export; a useful verdict says “the live RTSP session retained its ID, SSRC changed at 10:14:03, sequence/timestamp reset, no BYE preceded it, and the new H.264 source sent an IDR 2.1 seconds later.”

What proves a client handles the new SSRC correctly?

Replay or reproduce the boundary and record whether the receiver creates a new source context, resets loss/reordering state, accepts fresh RTCP sender reports, obtains required codec configuration, and resumes at a keyframe. Do not merge sequence numbers across SSRCs merely because payload type and endpoint remain the same.

Compare an expected camera profile switch or failover with the unexpected event. The pass condition is not only “video returned”; it is a bounded recovery time with no stale jitter/loss calculation and no use of parameter sets from the retired source. Keep the old and new source summaries in the same case report so the server and client owners can verify the transition.

Acceptance also includes cleanup: the retired source must not keep a decoder, jitter buffer, or stale “stream alive” indicator indefinitely. Record that cleanup boundary and the first decodable frame from the replacement source.

Related guides

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