1362456 - Firefox should dynamically adjust the sending bitrate based on rembs

Status: NEW

(Core :: WebRTC: Networking, defect, P2)

Description

[Francesco Durighetto]

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

Steps to reproduce:

take 2 different computer connected to 2 different networks.
pc1 connected to network 1 (20mbit down / 900kbit up)
pc2 connected to network 2 (100 mbit symmetric).
try any free video chat website (ex. test were done on appear.in (I tried the same test in various platform, including my own Licode implementation)).
start a call -> smooth. nice (webcam 640x480).
pc1 start screensharing (1440x900)


Actual results:

inspecting the network, pc1 is uploading 1,4 mbit of data, while, obviously, pc2 is receiving only 900 kbit due to the pc1 upload network bottleneck).
on pc2 i'm decoding only 1 fps every 4/5 seconds and sending tons of nack and plis


Expected results:

Firefox should send a lower bitrate screensharing and adapt to network condition.
for example if pc1 is firefox and pc2 is chrome, chrome send rembs to firefox and firefox should adapt himself. but, again, firefox's trying to send tons packet that will be lost in the network.
if we try the same thing chrome to chrome we can see a much smoother experience (3fps avg.) and an average output of 450 kbit/s. also the quality is super good.

seems that firefox isn't dinamically adjusting sending bitrate based on rembs.
Am I missing something?

In a one to one scenario where the client acquires his stream in 720p but doesn't have a nice connection the other end only sees one keyframe time to time. also the audio can decrease in quality due to congestion.

Comment 1

[Nils Ohlmeier [:drno]]

Sounds like this is a similar problems as reported in bug 1362450.

Comment 2

[Francesco Durighetto]

it's not very clear to me if Firefox should have a mechanism that dinamycally adapt its bitrate based on RR / REMBS and it's not working or it's not implemented yet. 
how does it work?

Comment 3

[Alex Chronopoulos [:achronop]]

Nils, can you provide the answer in the question above?

Comment 4

[Francesco Durighetto]

It would be nice. 
Also Chrome adjust not only the bitrate butalso the resolution.
Firefox seems to maintain the getusermedia resolution no matter what.
The result on a bad connection is very poor. Sometimes not usable at all

Comment 5

[Nils Ohlmeier [:drno]]

In general Firefox should adapt it's sending bitrates based on RR. And we should adapt by changing resolution and/or frame rates.
If bitrate adaption by frame rate and resolution with RR does not work we would appreciate a separate bug report for that.

The REMB support got added to Firefox more recently if I'm not mis-taken and therefore might still have bugs.

Comment 6

[Francesco Durighetto]

ok so,
I'll open another bug for the RRs.
anyway, if RRs doesn't work, submitting REMBS should do the same job, right?
But I can't see this mechanism work.
Can anyone confirm the issue so maybe someone will start work on it?
the encoder never change its bitrate and/or resolution so it's impossible to make a video call if the network upload speed is < of the selected GUM resolution bitrate.

To reproduce easily:
* Call between Firefox and chrome (for debug purpose, chrome://webrtc-internals) on two different pcs.
* Firefox publish
* Chrome subscribe
* Limit download bandwidth on chrome (es. in OSX using Link Conditioner).

Instead of send Firefox adapting itself, we can see lots of freezes and a frame decoded time to time.
if we look at the chrome's receive available bandwidth we can see that the value is correct, but it's ignored in Firefox which continues to send large amount of packets which will be lost in the path.

the same test done in chrome to chrome results in a smooth experience.
I'm also trying to download the Firefox prebuilt VM to compile it, but i'm not familiar with C so I don't think I will be able to help a lot guys.
but for debug/testing I'm at your disposal.
cheers

Comment 7

[Byron Campen [:bwc]]

Any idea what might be going on here?

Comment 8

[duanpei]

I had a couple of tests on content sharing video streams. REMB does not work. But REMB does work in Cam video in controlling bit-rate.

I used Win 7 and 10.

Comment 9

[duanpei]

I tested with version 54-57.

Comment 10

[Andreas Pehrson [:pehrsons]]

Dan, could you take a look at this? At least to follow up on comment 8.

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

A log with MOZ_LOG=timestamp,signaling:5,webrtc_trace:5 WEBRTC_TRACE_FILE=nspr MOZ_LOG_FILE=some file would help.  (Run firefox with those environment variables set)

It seems odd that REMB (and RR) wouldn't adjust the rate for a screenshare.  In general, the code doesn't care where the stream comes from, except for deciding how many temporal streams to use - but that's more recent than FF 54.  There may be a big difference in the FPS or resolution compared to a video stream, but that still should be ok.

Comment 12

[Dan Minor [:dminor]]

I tested this using the setup described in comment 6 using appear.in. I ran Chrome on OS X and used Link Conditioner to change the network bandwidth. On Ubuntu, I ran either Chrome or Firefox, and shared my screen. In both cases, the screen share included the appear.in session so that I was sharing back the camera image from OS X.

Limiting bandwidth to 1.5Mbps seemed to result in roughly equivalent performance between Chrome and Firefox. Dropping the bandwidth down to 1Mbps more or less made the Firefox video freeze while Chrome continued to update, although it was pretty rough.

As mentioned by the reporters, I did not see a difference between Chrome and Firefox for camera calls. I'm going to call this confirmed and update the summary accordingly.

Comment 13

[Dan Minor [:dminor]]

Although if the screen share is larger resolution than the camera, perhaps the bandwidth settings I chose were not small enough to see a difference between Chrome and Firefox when using the camera.

Comment 14

[Dan Minor [:dminor]]

Sure enough, with the camera if I drop the bandwidth down to 250Kbps, Chrome performs better than Firefox. Sorry for the churn on the bug.

Comment 15

[Jacek Stypuła]

Is this going to be addressed in near future?

Comment 16

[Andre Klapper]

Jacek: Yes if you (or anyone else interested in seeing this implemented) provide a patch which fixes this ticket.