WebRTC ScreenShare Stream Transfer to new Tab - Low resolution Video

383 views
Skip to first unread message

Behzad Javani

unread,
Nov 9, 2023, 2:42:23 AM11/9/23
to discuss-webrtc
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

unread,
Nov 21, 2023, 11:05:38 AM11/21/23
to discuss-webrtc
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

unread,
Dec 6, 2023, 4:55:48 AM12/6/23
to discuss-webrtc
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

unread,
Dec 6, 2023, 11:22:01 AM12/6/23
to discuss-webrtc
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?
Screenshot 2023-12-06 at 10.18.38 AM.png
Also, how does the SDP for offer/answer look like? Could it be that REMB is used instead of TCC?

Behzad Javani

unread,
Jan 18, 2024, 11:46:27 AMJan 18
to discuss-webrtc
Sorry for the delay, I just noticed my response didn't go through. so I am sending it again
Screenshot 2024-01-17 at 9.06.33 AM.png

Paweł Domas

unread,
Jan 18, 2024, 12:15:13 PMJan 18
to discuss-webrtc
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:

Screenshot 2024-01-18 at 11.11.14 AM.png

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.
Reply all
Reply to author
Forward
0 new messages