1760050 - Outgoing screensharing bitrate is ~200kbps using H264

Status: NEW

(Core :: WebRTC, defect, P2)

Description

[Jim Mathies [:jimm]]

Screen sharing issues in Teams -

We are observing that FF sends screensharing with bitrate ~200kbps (when sender's maxbitrate is set to 3000kbps).

This might be related that sender's bitrate is set to lower value initially and then increased up to 3000kbps in few steps.

You could see several .setParameters() calls with different maxBitrate value

I tried to call .setParameters() always with some big maxBitrate (eg. 3000000) and I see that sharing bitrate is not limited in this case

You can repro using Teams: join a meeting from FF and start screen sharing a youtube video for better effect.

Comment 1

[Nico Grunbaum [:ng, @chew:mozilla.org]]

At first glance I would suspect bandwidth estimation. It would be useful to attach the contents about:webrtc which should contain the bandwidth estimations.

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Please include repro steps for the described actions (is this a fiddle?). Also what platform(s) is this observed on? (We're seeing quite different performance on screensharing per platform, so this might be useful info).

Comment 3

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Jim Mathies [:jimm] from comment #0)

We are observing that FF sends screensharing with bitrate ~200kbps (when sender's maxbitrate is set to 3000kbps).

If this value was observed in about:webrtc note that that's 200KBPs (kiloBYTES/s) not kbps (kilobits/s). It's an unfortunate typo fixed by bug 1760687 which should be in tomorrow's nightly (note the fix changes the unit not the numbers). maxBitrate in the API is in bps, so this alone might explain the discrepancy (x8).

You can repro using Teams: join a meeting from FF and start screen sharing a youtube video for better effect.

I also found Youtube or some video source necessary since the observed outgoing bitrate will drop otherwise when there are few if any changes in the video output to send, because codecs.

Here's what I did:

1. Open https://www.youtube.com/watch?v=QrC8yyp32wY;vq=hd1080 in a large Firefox window B and hit play (make sure it's HD/1080p)
2. Open https://jsfiddle.net/jib1/284cbt5d/show in Firefox window A, hit Start! button and capture Firefox window B

On Windows 10 if I max out all the sliders, I get 1413x1018x30 fps received, with rates varying between ~320 KBps to ~850 KBps depending in large parts on what's in the video FWICT (darker shots = lower rate).

These numbers seems reasonable to me, and match what I see in Chrome using the same fiddle. If you observe vastly different numbers with that fiddle, please report.

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

These numbers seems reasonable to me, and match what I see in Chrome using the same fiddle.

Actually, Chrome drops the frame rate to around ~15 fps, while Firefox keeps it steady at 30 fps (a regression). I've filed bug 1760843 on this.

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Original reporter said they were using H264. Here's an H264 version of the fiddle: https://jsfiddle.net/jib1/02j8q6h9/show

I'm still not able to reproduce sub-1000 kbps when capturing a youtube video with it, but I'm seeing some color artifacts. I've filed bug 1761143 on those.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

I can reproduce sub-1000 kbps when capturing a youtube video: "270,320 bps = 270.32 kbps = 33.79 KBps" on macOS

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mjf, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Jim Mathies [:jimm]]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #3)

(In reply to Jim Mathies [:jimm] from comment #0)

We are observing that FF sends screensharing with bitrate ~200kbps (when sender's maxbitrate is set to 3000kbps).

If this value was observed in about:webrtc note that that's 200KBPs (kiloBYTES/s) not kbps (kilobits/s). It's an unfortunate typo fixed by bug 1760687 which should be in tomorrow's nightly (note the fix changes the unit not the numbers). maxBitrate in the API is in bps, so this alone might explain the discrepancy (x8).

You can repro using Teams: join a meeting from FF and start screen sharing a youtube video for better effect.

I also found Youtube or some video source necessary since the observed outgoing bitrate will drop otherwise when there are few if any changes in the video output to send, because codecs.

Here's what I did:

1. Open https://www.youtube.com/watch?v=QrC8yyp32wY;vq=hd1080 in a large Firefox window B and hit play (make sure it's HD/1080p)
2. Open https://jsfiddle.net/jib1/284cbt5d/show in Firefox window A, hit Start! button and capture Firefox window B

On Windows 10 if I max out all the sliders, I get 1413x1018x30 fps received, with rates varying between ~320 KBps to ~850 KBps depending in large parts on what's in the video FWICT (darker shots = lower rate).

These numbers seems reasonable to me, and match what I see in Chrome using the same fiddle. If you observe vastly different numbers with that fiddle, please report.

Running this test, I'm currently seeing 0-15 fps depending on the bandwidth slider. I can't get it to go above 15fps.