RTMP/WHIP Stream "Tape Recorder Effect" During Packet Loss

[mpisat]

Description

When experiencing packet loss during WHIP streaming, the ingress pipeline exhibits a "tape recorder effect" where:

1. Latency gradually increases
2. When RTMP publishing is stopped, the pipeline continues playing back buffered content for several seconds. We don't have this issue with WHIP because of WHIP delete session kicking in.
3. The system never catches up to real-time after packet loss occurs

This creates a continuously growing delay between source and output, particularly noticeable in interactive streaming scenarios.

Root Cause

The targetMinQueueLength constant in webrtc_sink.go is set to 2, which isn't aggressive enough for detecting when the pipeline should drop frames to catch up after packet loss. This results in the system preserving timing relationships rather than prioritizing real-time delivery.

Reproduction Steps

1. Set up a LiveKit ingress with WHIP input and transcoding enabled
2. Stream with H.264 encoding
3. Introduce network packet loss (can be simulated with network traffic shapers)
4. Observe growing latency between source and output
5. Stop RTMP publishing and note that pipeline continues playing old content, if WHIP used, it can terminate with Delete request.

Solution

Setting targetMinQueueLength = 0 in webrtc_sink.go resolves the issue by making the system more aggressive in detecting when it needs to drop frames to maintain real-time playback. This only works in packet loss scenario (tested with 2% upload packet loss, using H264 codec)

Proposed Fix

// In webrtc_sink.go
const (
    targetMinQueueLength = 0  // Changed from 2
)

This simple change makes the system immediately respond to any queue buildup during packet loss by triggering the "playing too slow" condition and dropping frames to catch up.

Additional Context

This issue becomes particularly problematic in interactive streaming scenarios where maintaining low latency is critical. The current behavior prioritizes preserving all frames over maintaining real-time delivery.

Note: This fix resolves the issue for WHIP input specifically. RTMP input requires additional changes to address similar behavior.

[mpisat]

Update: tape recorder effect still happens on WHIP if I cap upload bandwidth (e.g to simulate temporary network issue) and uncap it after 10s or so.

[mpisat]

With the suggested modification above (one line change)
During 2% packet loss

After packet loss disabled -- recovers quickly

With latest ingress (no modification) - 10 to 15s packet loss, and then stop inducing packet loss, latency goes from 800ms to 3 seconds with transcoding.

Video bitrate 5000 Kbps. Server latency is 180ms to my location. WHIP really works much better in this case, RTMP really suffers in packet loss.

[biglittlebigben]

The fix suggested has an impact on A/V sync.

[mpisat]

targetMinQueueLength = 0 really causes a/v sync, I should have caught it earlier.
from now on I'll use a test video in OBS that can tell A/V lipsync easily.