WebRTC ScreenShare Stream Transfer to new Tab - Low resolution Video

[Behzad Javani]

We have developed a piece of logic to transfer the video feed (associated with screen sharing) from the existing tab to a new tab (using the instructions here). However, we are encountering an issue where the video stream in the new tab initially displays at a very low resolution. It takes approximately 20-40 seconds for the resolution to improve. Notably, this behavior is specific to Chromium-based browsers, while it performs as expected in Firefox and Safari. We have explored potential solutions suggested in various StackoverFlow posts. These solutions primarily involve modifying the SDP message to include "x-google-max-bitrate" or, as an alternative approach, adding "b=AS:10000" to bypass Chrome's 300KBps bandwidth limit, however, we haven't seen any difference in behavior.

[Paweł Domas]

What do you see in webrtc internals for this call? Do you see it as resolution (width and height of the video) being low? How does the bitrate graph look like and what are the transport stats (available bandwidth)?

It is strange for the ramp up to take so long. 20-40 seconds seems too much.

[Behzad Javani]

Thanks for the response. the Frame width and height start at 640x360; it then increases to 960x540, then 1280x720, and finally 1920x1080. the outgoing bitrate is 300000.
I have noticed when the video stream includes low information content (a white screen with some black text in it), the resolution increases at a much higher pace; for streams with higher information content (a YouTube video), it's painfully slow.
It's worth mentioning that in Firefox, for example, the resolution starts at 1486 x 836 and increases to 1920x1080 in less than 20 secs most of the time. 

[Paweł Domas]

On Wednesday, December 6, 2023 at 3:55:48 AM UTC-6 Behzad Javani wrote:

Thanks for the response. the Frame width and height start at 640x360; it then increases to 960x540, then 1280x720, and finally 1920x1080. the outgoing bitrate is 300000.
I have noticed when the video stream includes low information content (a white screen with some black text in it), the resolution increases at a much higher pace; for streams with higher information content (a YouTube video), it's painfully slow.

That makes sense:

- white/still video needs little bitrate

- a movie with lots of movement and changes will max out the bitrate budget

 

It's worth mentioning that in Firefox, for example, the resolution starts at 1486 x 836 and increases to 1920x1080 in less than 20 secs most of the time. 

Can you show the availableOutgoingBitrate graph on the selected candidate-pair?

Also, how does the SDP for offer/answer look like? Could it be that REMB is used instead of TCC?

[Behzad Javani]

Sorry for the delay, I just noticed my response didn't go through. so I am sending it again

[Paweł Domas]

So it looks like the estimate available outgoing bitrate is happily stable at 300 which means Chrome is not even trying to send more. That will result in a blurry video anytime there's more movement. This also makes me think it's not a problem with the throughput/bandwidth estimation, but outgoing stream configuration.

 You may want to check the target bitrate on the outgoing video stream stats to see how is the stream configured:

It must be something in the way you're using WebRTC APIs. I'd enable debug webrtc logs in chrome and compare the two flows, check on the SDPs offer/answer and compare what's different. The goal is to get the target bitrate higher.