Closed Bug 1877675 Opened 2 years ago Closed 2 years ago

Firefox doesn't render video received from Chrome

Categories

(Core :: WebRTC, defect)

Product:
Core
Component:
WebRTC
Version:
Firefox 122
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: pehrsons, Assigned: bwc)

References

(Depends on 1 open bug)

Details

Originally filed as bug 1877552, but that was masked by a Nightly-only DTLS 1.3 issue. Let's restart here.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Steps to reproduce:

  1. Start a p2p call between Chrome 120 and Firefox 122 on https://meet.jit.si.
  2. Rejoin the call from Firefox a couple of times until you see black video for remote peer on Firefox.

Actual results:

Firefox stops rendering the video received from Chrome. The browser doesn't fire the 'canplaythrough' event indicating that it doesn't have enough date to render the media. There are no PLIs or NACKs reported on the sender in Chrome://webrtc-internals and Chrome doesn't report a cpu or bandwidth limitation either in its stats.

This happens only when the media flows directly between the browsers and not through the SFU. The sender is using a VP8 encoder with scalabilityMode set to L1T1.

Link to the profile captured when the issue was reproduced: https://share.firefox.dev/42lSzbp

Expected results:

Firefox should have rendered the video received from Chrome.

Copy-paste from the original bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1875686) :

We have recently contacted Jitsi and they have recognised that there was a bug on their side. The working solution (even for Nightly) was deployed in boris.jitsi.net. I hope that they will soon deploy it in master.

The currently working solution: You go to about:config, then you change media.peerconnection.dtls.version.max to 771.

I managed to reproduce the bug. Investigating.

Depends on: 1877715

Here is a profile with logging (WebRTC preset) from a repro of this bug in 122 release. Note that I could only start the logging after seeing the issue, because of bug 1877715. Nothing obvious, incoming RTP traffic is present while no frames get decoded.

The DTLS issue is on the bridge PeerConnection. Jitsi client opens 2 PeerConnections in a 2 person call. One to the JVB and the other to the remote peer directly. Usually JVB ICE gets established first and media starts flowing over the JVB connection and that is probably why media was getting decoded for few seconds.
As soon as P2P ICE gets established between the peers directly, the client suspends media over the JVB connection and swaps out the remote JVB tracks that are attached to the video elements for the P2P tracks that get signaled for the P2P connection. P2P is the problematic one. There could be different scenarios for P2P.

  1. Chrome is the offerer - in this case, the client first adds a recvonly transceiver when the remote description is set. The local tracks on Firefox are added before creating the answer and the transceiver direction changes to sendrecv.
  2. Firefox is the offerer - in this case, the local tracks are added on Firefox first and the offer is generated. Therefore, the direction of the transceiver is set to sendonly initially and when the answer is received from the remote peer, it is changed to sendrecv.

My observation is that the issue reproduces in both the cases.

Are you sure that it's a DTLS issue?
I am asking because we have recently added support for DTLS1.3 in Nightly, and I am curious if it was that caused the problem. Even if the Release version is not using DTLS1.3, but we already observed a problem caused by it (but in Nightly). Luckily, the problem was not with our code (see here: https://bugzilla.mozilla.org/show_bug.cgi?id=1875686#c12).

Flags: needinfo?(jaya.allamsetty)

I don't think it's a DTLS issue. The DTLS issue happens on with a bridge connection but in this case, the peer connection is established directly between the browsers. Also I am able to reproduce it in Firefox 122.

Flags: needinfo?(jaya.allamsetty)

Per the pernosco recording, RtpVideoStreamReceiver2::payload_type_map_ contains pts 96, 98 and 108 when receiving is successful, but 97 and 120 when failing. In both cases the pt of the incoming packets is 96 When successful the pt of the incoming packets is 96, and when failing it is 122, i.e. RED.

(In reply to Andreas Pehrson [:pehrsons] from comment #8)

Per the pernosco recording, RtpVideoStreamReceiver2::payload_type_map_ contains pts 96, 98 and 108 when receiving is successful, but 97 and 120 when failing. In both cases the pt of the incoming packets is 96.

And in that recording, 96 is not present in our local SDP, so those incoming packets are bad. Maybe there's some quirk on our end that's preventing 96 from being used in our SDP.

The last SetRemoteDescription sdp before we start failing to receive video contains

v=0
o=mozilla...THIS_IS_SDPARTA-99.0 4197372987280504236 1 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 FD:52:DE:F2:75:79:18:3C:21:2C:14:6B:71:10:F6:46:CF:00:63:4E:11:00:61:0E:8E:34:FE:68:B9:ED:D0:EC
a=ice-options:trickle
a=msid-semantic: WMS *
a=group:BUNDLE 0 1
m=audio 54566 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 0.0.0.0
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000/1
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=setup:passive
a=mid:0
a=msid:{0f7d70ef-d8ed-4436-84b1-292c8dcceb8c} {0621d290-7bf5-4f67-89bc-2206600010bb}
a=sendrecv
a=ice-ufrag:1fdecb39
a=ice-pwd:e8da4ed883799a6d36c2d398b538d9f3
a=candidate:0 1 UDP 2122187007 x.x.x.x 45642 typ host
a=candidate:3 1 UDP 2121990399 x.x.x.x 50588 typ host
a=candidate:6 1 UDP 2121924863 x.x.x.x 47292 typ host
a=candidate:9 1 UDP 2122055935 x.x.x.x 34833 typ host
a=candidate:12 1 UDP 2122252543 x:x:x:x:x:x:x:x 57803 typ host
a=candidate:15 1 UDP 2122121471 x:x:x:x:x:x:x:x 53242 typ host
a=candidate:18 1 TCP 2105458943 x.x.x.x 9 typ host tcptype active
a=candidate:20 1 TCP 2105262335 x.x.x.x 9 typ host tcptype active
a=candidate:22 1 TCP 2105196799 x.x.x.x 9 typ host tcptype active
a=candidate:24 1 TCP 2105327871 x.x.x.x 9 typ host tcptype active
a=candidate:26 1 TCP 2105524479 x:x:x:x:x:x:x:x 9 typ host tcptype active
a=candidate:28 1 TCP 2105393407 x:x:x:x:x:x:x:x 9 typ host tcptype active
a=candidate:1 1 UDP 1685987327 x.x.x.x 45642 typ srflx raddr x.x.x.x rport 45642
a=candidate:4 1 UDP 1685790719 x.x.x.x 50588 typ srflx raddr x.x.x.x rport 50588
a=candidate:7 1 UDP 1685725183 x.x.x.x 47292 typ srflx raddr x.x.x.x rport 47292
a=candidate:2 1 UDP 92151295 130.61.132.30 54566 typ relay raddr x.x.x.x rport 54566
a=candidate:5 1 UDP 91954687 130.61.132.30 55027 typ relay raddr x.x.x.x rport 55027
a=candidate:10 1 UDP 1685856255 x.x.x.x 34833 typ srflx raddr x.x.x.x rport 34833
a=candidate:11 1 UDP 92020223 130.61.132.30 59656 typ relay raddr x.x.x.x rport 59656
a=candidate:8 1 UDP 91889151 130.61.132.30 63566 typ relay raddr x.x.x.x rport 63566
a=candidate:19 1 UDP 8265727 130.61.132.30 63131 typ relay raddr x.x.x.x rport 63131
a=candidate:21 1 UDP 8069119 130.61.132.30 58385 typ relay raddr x.x.x.x rport 58385
a=candidate:23 1 UDP 8003583 130.61.132.30 62686 typ relay raddr x.x.x.x rport 62686
a=ssrc:900609211 cname:{181b4608-1ffe-40a3-b2af-943d07e4e7b0}
a=rtcp-mux
m=video 9 UDP/TLS/RTP/SAVPF 120 97 126 124 98 127 122 119
c=IN IP4 0.0.0.0
a=rtpmap:120 VP8/90000
a=rtpmap:124 rtx/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 rtx/90000
a=rtpmap:126 H264/90000
a=rtpmap:127 rtx/90000
a=rtpmap:122 red/90000
a=rtpmap:119 rtx/90000
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:124 apt=120
a=fmtp:98 apt=97
a=fmtp:127 apt=126
a=fmtp:119 apt=122
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-fb:97 transport-cc
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-fb:122 nack
a=rtcp-fb:122 nack pli
a=rtcp-fb:122 ccm fir
a=rtcp-fb:122 goog-remb
a=rtcp-fb:122 transport-cc
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=setup:passive
a=mid:1
a=msid:{5c9ec04b-f868-42dc-af66-798f9849fe2a} {7ce7a131-3abe-4573-84fd-5692c4a03068}
a=sendrecv
a=ice-ufrag:1fdecb39
a=ice-pwd:e8da4ed883799a6d36c2d398b538d9f3
a=ssrc:3266073160 cname:{181b4608-1ffe-40a3-b2af-943d07e4e7b0}
a=ssrc:1353191428 cname:{181b4608-1ffe-40a3-b2af-943d07e4e7b0}
a=ssrc-group:FID 3266073160 1353191428
a=rtcp-mux

So then js seems to be on board but the sender sends the wrong pt? Jaya, can you confirm?

Flags: needinfo?(jaya.allamsetty)

Hang on, this is not adding up...

There seem to be two offer/answer exchanges going on at the same time here...

When the call is still on the JVB media connection, packets arriving from Chrome should have PT 101/97 - those are VP9 packets.
After the call switches over to p2p media connection, packets arriving from Chrome have PT as 120/124 - those are VP8 packets.

Flags: needinfo?(jaya.allamsetty)

(In reply to Byron Campen [:bwc] from comment #12)

There seem to be two offer/answer exchanges going on at the same time here...

Yes, Jitsi opens 2 PeerConnections, one to the bridge and the other to the remote Chrome browser directly.

Ok, one of those PeerConnections seems to negotiate payload types 100 and 96 for VP8 and RTX, respectively. The other negotiates payload types 120 and 124 for VP8 and RTX, respectively. We are seeing payload type 96 in recv packets, but the question is whether we're seeing them on the right PeerConnection.

Yes, the JVB negotiates PTs 100/96 for VP8/RTX and 101/97 for VP9/RTX with Firefox and packets start arriving on this PeerConnection first since JVB ICE is established first. Chrome sends VP9 packets over the JVB PeerConnection Firefox should see packets with PR 101 and 97 for the first few seconds until P2P ICE is established. Once that happens, Chrome starts encoding video using VP8 and the incoming packets on Firefox should have PT 120 and 124. This is what Chrome webrtc stats reports.

Looking some more at the pernosco trace, it seems that once video stops flowing, we are only receiving packets with the payload types 109 (opus), 119 (RTX for RED (what!?)), 122 (RED), and 124 (RTX for VP8). I'd like to see what the offer/answer exchange looks like from Chrome's perspective...

Edit: Looking more, it seems that we never see a packet with the payload type 120 over the course of the entire test.

https://share.firefox.dev/48Mu7lL - here is the profile for a successful p2p call between Chrome and Firefox

Chrome is the offerer in this case and the PTs for VP8 and RTX are 96 and 97, respectively. The issue seems to reproduce only when the PTs are 120/124 which mostly happens only when Firefox is the offerer. I saw one case when Firefox is the offerer and generates 96 and 97 as PTs for VP8 and RTX and Chrome answers with the same PTs and Firefox was able to decode and render the video but haven't been able to reproduce it since then.

SDP for the successful case.
m=video 9 UDP/TLS/RTP/SAVPF 96 39 127 108 106 104 102 98 45 99 97 40 125 109 107 105 103 46 112 113
c=IN IP4 0.0.0.0
a=rtpmap:98 VP9/90000
a=rtpmap:96 VP8/90000
a=rtpmap:39 H264/90000
a=rtpmap:127 H264/90000
a=rtpmap:108 H264/90000
a=rtpmap:106 H264/90000
a=rtpmap:104 H264/90000
a=rtpmap:102 H264/90000
a=rtpmap:45 AV1/90000
a=rtpmap:99 rtx/90000
a=rtpmap:97 rtx/90000
a=rtpmap:40 rtx/90000
a=rtpmap:125 rtx/90000
a=rtpmap:109 rtx/90000
a=rtpmap:107 rtx/90000
a=rtpmap:105 rtx/90000
a=rtpmap:103 rtx/90000
a=rtpmap:46 rtx/90000
a=rtpmap:112 red/90000
a=rtpmap:113 rtx/90000
a=fmtp:39 profile-level-id=4d001f;level-asymmetry-allowed=1
a=fmtp:127 profile-level-id=4d001f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:108 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:106 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:104 profile-level-id=42001f;level-asymmetry-allowed=1
a=fmtp:102 profile-level-id=42001f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:99 apt=98
a=fmtp:97 apt=96
a=fmtp:40 apt=39
a=fmtp:125 apt=127
a=fmtp:109 apt=108
a=fmtp:107 apt=106
a=fmtp:105 apt=104
a=fmtp:103 apt=102
a=fmtp:46 apt=45
a=fmtp:113 apt=112
a=rtcp:1 IN IP4 0.0.0.0
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:39 goog-remb
a=rtcp-fb:39 transport-cc
a=rtcp-fb:39 ccm fir
a=rtcp-fb:39 nack
a=rtcp-fb:39 nack pli
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=rtcp-fb:106 goog-remb
a=rtcp-fb:106 transport-cc
a=rtcp-fb:106 ccm fir
a=rtcp-fb:106 nack
a=rtcp-fb:106 nack pli
a=rtcp-fb:104 goog-remb
a=rtcp-fb:104 transport-cc
a=rtcp-fb:104 ccm fir
a=rtcp-fb:104 nack
a=rtcp-fb:104 nack pli
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=rtcp-fb:45 goog-remb
a=rtcp-fb:45 transport-cc
a=rtcp-fb:45 ccm fir
a=rtcp-fb:45 nack
a=rtcp-fb:45 nack pli
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=setup:actpass
a=mid:1
a=sendrecv
a=ice-ufrag:PNkO
a=ice-pwd:SiJlM3iyNXxlXRiItpkqWK6z
a=fingerprint:sha-256 F7:9F:5C:29:87:8C:3D:51:CC:80:BD:14:AB:6F:63:41:D0:06:C6:3F:E5:53:A8:9E:CB:E9:25:BA:B2:E2:5F:29
a=ssrc:2732314846 msid:db9df6b2-video-0-1 50405dcd-0cb7-45b4-aa07-38a9156d0d27-1
a=ssrc:3799198424 msid:db9df6b2-video-0-1 50405dcd-0cb7-45b4-aa07-38a9156d0d27-1
a=ssrc-group:FID 2732314846 3799198424
a=rtcp-mux

This issue seems to reproduce only when the PTs are 120 and 124. I hope this helps.

If Firefox is sending an offer with payload type 120, Chrome must use payload type 120 for packets it transmits. There's no wiggle room here. And, as far as I know, Chrome does not have any bugs where it would ignore the payload types in the offer. Additionally, the answer we're getting for Chrome does not look like Chrome 121's SDP (eg; the source-level msid attributes, the lack of a source-level cname attribute, a=rtcp:1 instead of a=rtcp:9, etc). There's some sort of middlebox shenanigans going on here. I would need to see the offer/answer exchange from Chrome's perspective.

Assignee: nobody → docfaraday

I tried testing this out, and Chrome appears to expose the most recent offer/answer exchange in chrome://webrtc-internals. There are some differences in the SDP offer Chrome sees and what we sent, but the payload types look fine. I do wonder what those earlier exchanges looked like from Chrome's perspective.

After some more looking, there are only 4 packets for the VP8 RTX (pt 124), and none of them carry any actual data apparently; they're just padding. So it does not seem that Chrome has transmitted any VP8 at all.

This really seems like something is going wrong either in Jitsi and/or Chrome. We are negotiating to receive VP8 (120) with RTX (124) and receiving neither.

Thank you, I will gather some logs on the Chrome side to see if the media being sent on the right PeerConnection. A quick look at Chrome WebRTC-internals didn't indicate otherwise but I will keep looking.

Can you see if ulpfec is being seen on Chrome's side in the SDP. From what I see in my testing it appears that we are getting an offer with just red and no ulpfec so we answer back with just red. Chrome is showing that ulpfec is listed with PT 123 when it does it's setRemoteDescription as such Chrome is choosing to send us the RED packets that most likely contain the VP8 data and ULPFEC as needed. I wonder if something in the middle is adding ulpfec back for the Chrome side or if there is something in Chrome where it is choosing to add ulpfec when it was not signaled.

FireFox SDP from about:webrtc

a=rtpmap:120 VP8/90000
a=rtpmap:97 H264/90000
a=rtpmap:126 H264/90000
a=rtpmap:124 rtx/90000
a=rtpmap:98 rtx/90000
a=rtpmap:127 rtx/90000
a=rtpmap:122 red/90000
a=rtpmap:119 rtx/90000

Chrome SDP from setRemoteDescription in webrtc-internals:

a=rtpmap:120 VP8/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=rtpmap:124 rtx/90000
a=rtpmap:127 rtx/90000
a=rtpmap:98 rtx/90000
a=rtpmap:123 ulpfec/90000
a=rtpmap:122 red/90000
a=rtpmap:119 rtx/90000

If the SDP Firefox was getting also contained ulpfec my hunch is we would work with that as ULPFEC/RED for video should be functional now.

Flags: needinfo?(jaya.allamsetty)

If the SDP Firefox was getting also contained ulpfec my hunch is we would work with that as ULPFEC/RED for video should be functional now.

This is spot on. Jitsi client filters ulpfec out from the codecs passed to the setCodecPreferences call because of a Chrome bug. So the offer/answer created by Chrome doesn't have ulpfec in supported codecs and it doesn't get negotiated with Firefox. The initial setRemoteDescription has ulpfec in it but the local description doesn't have it and yet Chrome decides to send packets that contain VP8 data and ULPFEC. Is that expected?

If I comment out this code, video works every time on Firefox even when it is the offerer.

Flags: needinfo?(jaya.allamsetty)

(In reply to jaya.allamsetty from comment #25)

If I comment out this code, video works every time on Firefox even when it is the offerer.

Jaya is there a way to disable ulpfec all together?
Maybe that would work better across all browsers.

Flags: needinfo?(jaya.allamsetty)

(In reply to jaya.allamsetty from comment #25)

If the SDP Firefox was getting also contained ulpfec my hunch is we would work with that as ULPFEC/RED for video should be functional now.

This is spot on. Jitsi client filters ulpfec out from the codecs passed to the setCodecPreferences call because of a Chrome bug. So the offer/answer created by Chrome doesn't have ulpfec in supported codecs and it doesn't get negotiated with Firefox. The initial setRemoteDescription has ulpfec in it but the local description doesn't have it and yet Chrome decides to send packets that contain VP8 data and ULPFEC. Is that expected?

If I comment out this code, video works every time on Firefox even when it is the offerer.

This seems like behavior I would expect, an endpoint is given SDP and acts on it to the best of it's ability. The error here seems to be that what is being signaled to both sides is not matching. This would be no different from calling setRemoteDescription and adding a codec/PT that the remote did not actually include in their SDP.

If you need to fully disable ULPFEC could you try to strip RED as well?

Yes, we should be able to drop ulpfec and RED across all browsers and make sure it is not negotiated at all. I am just curious why this bug surfaced now.

Flags: needinfo?(jaya.allamsetty)

We have been running p2p between Chrome and Firefox for over 9 months now but we got reports of this not working only recently. It is possible that we don't hit the case where Firefox is the offerer more often. Thank you all for helping us figure this one out.

(In reply to jaya.allamsetty from comment #29)

We have been running p2p between Chrome and Firefox for over 9 months now but we got reports of this not working only recently. It is possible that we don't hit the case where Firefox is the offerer more often. Thank you all for helping us figure this one out.

Nightly has ULPFEC/RED enabled for a while. Do you know if your testing includes Nightly? For release 122 is when it shipped on by default. You could also go into about:config on Firefox and set media.navigator.video.red_ulpfec_enabled to false to test and see if that resolve the issue to confirm it is due to ULPFEC/RED being on.

Flags: needinfo?(jaya.allamsetty)

Thanks everyone for diagnosing this. I could not reproduce with media.navigator.video.red_ulpfec_enabled=false. Closing as WFM.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(jaya.allamsetty)
Resolution: --- → WORKSFORME
See Also: → 1869453
You need to log in before you can comment on or make changes to this bug.