RTP SSRC Change Mid-Stream: Debugging Camera Restarts, Stream Source Changes, Sequence Resets, 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 for SEO because many people search for "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:

1. Identify all SSRC values per RTP track.
2. Locate the exact packet where SSRC changes.
3. Compare sequence numbers before and after.
4. Compare RTP timestamps before and after.
5. Check RTCP BYE and sender reports.
6. Check whether RTSP session ID changed.
7. Check whether payload type changed.
8. Look for keyframe or codec config after the boundary.
9. Separate source restart from network loss.
10. 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.