Firefox video issues

I’m testing with the latest Firefox 69 and Chrome 77 on MacOS 10.14.

  1. Join Firefox into the room:
  2. Join Chrome into the same room.

Till now everything works fine. All videos are visible.
Now add another Chrome browser.

  1. Join a second Chrome into the same room:

The second Chrome browser does not show the remote video from the Firefox source.

I tried the same scenario but without the forceH264=true so VP8 codec is used.
In the VP8 case it could take about 5-30 seconds till the second remote video from Firefox starts to flow.

If Safari or Chrome is used instead of Firefox in the above scenarios then everything works fine.

mediasoup and mediasoup-client provide lot of debugging capabilities for the application developer to check what happens. If you use them and encounter a real bug or issue, it’s ok to report it. However, just telling that the online demo app does not work in certain scenarios is not the way to go.

I’m just sharing my observations. It turned out that the issue is related to the simulcast feature. If simulcast is disabled with simulcast=false in the URL params then the issue is gone.

Also I ran everything on my dev machine. I checked the mediasoup server log. If Firefox is using simulcast then the log contains:

 mediasoup:WARN:worker[pid:31559] RTC::WebRtcTransport::OnRtpDataReceived() | DecryptSrtp() failed [ssrc:1646904201, payloadType:126, seq:27977] +0ms


mediasoup:WARN:worker[pid:31559] RTC::NackGenerator::GetNackBatch() | sequence number removed from the NACK list due to max retries [seq:32674] +0ms

If Firefox does not use simulcast then these warning are not present.
If Chrome or Safari are using simulcast these warning are not present also.

The SRTP decrypt error is legit since FF does not (yet) support RTX so it just resends the original media packet when mediasoup sends a NACK to it. If the packet arrives in disorder after mediasoup sent the NACK, SRTP decrypt will fail for the second one since the original one was already received.

BTW I cannot reproduce the issue but I do know that Firefox does not behave very well in bad network scenarios.

The issue is not related to bad network because it happens when both the client and the server are on my dev machine. So there is no packet loss.

The issue is related to Firefox + simulcast + H264.
The easiest way to reproduce it is:

  1. Join Firefox in the room
  2. Wait 20 seconds.
  3. Join Chrome in the room.

The result is: Chrome side does not see the Firefox video.
If step 2) is skipped then it ‘works’ fine.

which is a bug in libwebrtc that may also affect current Firefox stable until they update it:

Actually is more related to this bug: