Firefox <=> Chrome transport-cc issue after session renegotiation
Categories
(Core :: WebRTC: Signaling, defect, P2)
Tracking
()
People
(Reporter: fs, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36
Steps to reproduce:
A WebRTC session is established between Firefox and Chrome. Only Chrome sends a video track Firefox is receive only. Now Firefox ads a track as well (videos or audio) and the session is successfully renegotiated.
Actual results:
After a few seconds the quality of the video track send from Chrome to Firefox degrades, the framerate drops to 2-3 fps and the video starts to lag for a few seconds.
Expected results:
The video quality should remain the same as before the renegotiation.
This issue exists with all Firefox versions >= 80. It seems to be caused by transport-cc (https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01 ) which was enabled in Firefox 80. When i disable transport-cc in Firefox by setting media.navigator.video.use_transport_cc to "fals"e OR remove all transport-cc related lines from the SDP the issue does not appear.
The same renegotiation works fine with Firefox <=> Firefox and Chrome <=> Chrome.
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Signaling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•4 years ago
|
||
fs, thanks for your bug report. Could you upload the contents of about:webrtc
after letting the video run for a bit?
Sure... can i share this somehow non publicly since it contains some sensitive information such as IP addresses and URLs?
Comment 4•4 years ago
|
||
(In reply to fs from comment #3)
Sure... can i share this somehow non publicly since it contains some sensitive information such as IP addresses and URLs?
Sure, you can send it to my email if you like.
This is a little test case to reproduce the issue:
- Open this URL in Firefox and Chrome https://w2g.tv/rooms/fftest-7g10fv6j7h4sn52li0
- In Chrome enable your webcam (Button at the bottom)
- Wait until the video appears in Firefox
- In Firefox enable your microphone
- Wait a few seconds you should see the quality of the video send from Chrome to Firefox decrease, fps drop and that the video starts to lag
If you set media.navigator.video.use_transport_cc to false this does not happen.
Comment 7•4 years ago
|
||
Michael, do you think this could be related to some of the bandwidth limiter issues that you have been looking into? Transport-cc is supposed to give a transport wide view of congestion.
Comment 8•4 years ago
|
||
(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #7)
Michael, do you think this could be related to some of the bandwidth limiter issues that you have been looking into? Transport-cc is supposed to give a transport wide view of congestion.
Yes, it seems so. I just ran my tests with some instrumentation in place, and having turned off transport-cc I no longer see the drop in bandwidth after multiple negotiations. Interesting find. I'm going to link these bugs. They may be a straight up duplicate, but I'll wait a bit to decide that.
Comment 9•4 years ago
|
||
Same here, disabling transport-cc with any means helps with https://bugzilla.mozilla.org/show_bug.cgi?id=1690832 too, thanks for viable workaround!
Reporter | ||
Comment 10•4 years ago
|
||
Any update on this?
Description
•