Using the latest mediasoup 3.14.8 we're seeing constant freezes with simulcast.

mediasoup libraries
1

It seems to happen less frequently on 3.11.8 which we upgraded from. But it still seems to occur.

Some users can receive video fine, while others will be freeze-frame, for a while, and sometimes recover, sometimes they don’t.

We’re using VP8 with the following config:

return [
      {
        maxBitrate: 120_000,
        maxFramerate: 18,
        scaleResolutionDownBy: 4,
        scalabilityMode: "L1T2",
      },
      {
        maxBitrate: 350_000,
        maxFramerate: 24,
        scaleResolutionDownBy: 2,
        scalabilityMode: "L1T2",
      },
      {
        maxBitrate: 1_500_000,
        maxFramerate: 24,
        scaleResolutionDownBy: 1,
        scalabilityMode: "L1T2",
      },
    ];

The logs hint to a possible problem here:

2024-07-17T21:28:08.125Z mediasoup:WARN:Channel [pid:33] RTC::SimulcastConsumer::SendRtpPacket() | cannot switch stream due to too high RTP timestamp extra offset needed (8370), requesting keyframe

2024-07-17T21:28:09.094Z mediasoup:WARN:Channel [pid:33] RTC::SimulcastConsumer::SendRtpPacket() | giving up on proper stream switching after got a requested keyframe for which still too high RTP timestamp extra offset is needed (8370)

also around the same time, huge BWE changes:

2024-07-17T21:30:39.323Z mediasoup:WARN:Channel [pid:33] RTC::TransportCongestionControlClient::MayEmitAvailableBitrateEvent() | high BWE value decrease detected, notifying the listener [now:0, before:1889066]

2024-07-17T21:30:35.601Z mediasoup:WARN:Channel [pid:33] webrtc::AlrDetector::GetApplicationLimitedRegionStartTime() | large delta_time_ms: 3001, forcing alr state change

Any direction would be appreciated.

2

(Solved on latest)

1 Like