Bandwidth usage in Desktop Capture or Screen Sharing

[Qiusheng Jiang]

I can read stats data from chrome://webrtc-internals/ during screen sharing.

One thing I noticed is that even when there is no change on the sharing screen (still image), it's still using about 200Kb/s bandwidth. See the center part of below graph.

For screen sharing scenarios, like you are doing a presentation, most of the time the screen stays the same and it doesn't make sense to consume so much resources all the time.

Is there any investigation on this and do you plan to add any improvements to reduce the usage of bandwidth, at least during idle time?

Thanks!

[Vikas]

Thanks for the feedback, i tried to recreate with this demo, for me when there was no change (still image) then in webrtc-internals graph i noticed about a 100Kb/s. You can try with the same demo. I tested on chrome Version 31.0.1650.26 beta-m.  Incase you still see the problem you file an issue in the webrtc tracker.

/Vikas

[Qiusheng Jiang]

Vikas, thanks for the quick response!

Yes depending on the screen size (resolution) you have, the bandwidth usage varies from 100Kb/s to 500Kb/s. In your demo the res=640*480.

I am actually not complaining about 100Kb/s or 200Kb/s. I would expect 0Kb/s bindwidth usage (or at least less than 1Kb/s) for still images.

Even 100Kb/s is a lot of data for remote/mobile users.

I am curious what data is being transmitted over the 100Kb/s bandwidth since there is no update in the video.

Is this something that can be optimized by Chrome? I am planning to fire an issue once you acked.

Thanks again!

[Alexandre GOUAILLARD]

out of curiosity, have you tried to reduce the temporal resolution (fps) to in turn reduce the bandwidth? it seems that the bandwidth usage is related to resolution and not to content (in the absence of external constraint, like limited available bandwidth).

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Qiusheng Jiang]

Yes, the bandwidth usage is related to the resolution as well as the frame rate. Even with very low resolution (640*480) and frame rate (5fps), it's still consuming about 60Kb/s bandwidth in idle state (still image).

Again, no matter what resolution and frame rate user is using, it should not consume so much bandwidth.

[bryand...@gmail.com]

I think it is a problem with the vp8 realtime encoder and not specific to webrtc.

I brought this issue up on the webm-discuss list over 2 years ago.  Then Jon Koleszar said that they needed to look into it, but maybe that never happened.  Maybe you can file a bug against vp8/webm ?

See: https://groups.google.com/a/webmproject.org/forum/#!topic/webm-discuss/664BEpNdEEY

[Qiusheng Jiang]

Thanks for the information. You are right, the problem is not only related to screen sharing.

In a normal video call using camera, it's consuming high bandwidth as well even though the shot content is static.

I've filed an issue against WebRTC here: https://code.google.com/p/webrtc/issues/detail?id=2536

[Justin Uberti]

This is working as intended. We send padding data to ensure we have enough bandwidth to quickly send the needed video data when the input does change.

[Göran AP Eriksson]

Could You explain the reasons behind the padding in more detail? I can imagine situations that padding behavior is not desirable.

[Eric Davies]

Interesting. Is there anyway we can turn control this feature off from javascript?

The local university pays for it's internet connection on a bandwidth basis, so they use a packet shaper to throttle down steady high volume traffic. Your padding would probably trigger that. I imagine there are many other institutions doing the same.

Eric.

[Qiusheng Jiang]

You may have a good reason to maintain the bandwidth for real time video, but for screen sharing, I believe that's another story.

To me, it is perfectly fine to have a short time lagging during screen sharing, and the recipients don't have to get every single frame of the changes. Low bandwidth usage is much more important in this case.

 

So I have the same question as Eric, do we have a parameter in the media constraints that we can pass in to turn off the padding data?

[Justin Uberti]

We looked into this and it turns out that this particular case is not a padding issue. We are still trying to determine the actual problem.

On Sat, Oct 19, 2013 at 11:22 PM, Göran AP Eriksson <gap...@gmail.com> wrote:

Could You explain the reasons behind the padding in more detail? I can imagine situations that padding behavior is not desirable.

[Qiusheng Jiang]

Justin, just let you know that I opened an issue against WebRTC here: https://code.google.com/p/webrtc/issues/detail?id=2536

[Dennis E. Dowhy]

IMO the problem here is a codec one.  VP8 should not be used for screen sharing.  VP8 is a lossy motion codec. Using a lossy motion prediction encoder isn't really optimal, especially when not much on a screen changes over time.  Text isn't as clear when decoded and displayed due to the nature of those kinds of codecs.  It's much more bandwidth efficient, and much higher quality if a lossless screen capture codec was used instead such as ScreenPressor http://www.infognition.com/ScreenPressor/ , as every pixel is restored to it's original value and data is only transmitted when pixels change and on it's configurable full picture refresh interval.  

So there's not really a 'bug' with the current implementation of using VP8, it's just really inefficient both in quality and bandwidth as it was not meant to be used in this context.  The real issue is a lack of a lossless video codec in Webrtc.

[Qiusheng Jiang]

Hi Dennis,

I understand that VP8 is a lossy codec, but actually in my testings, the result is not bad.

I tried to share a PowerPoint Presentation in resolution 1920*1080 and I scrolled up/down the slides very quickly. It's using about 2.5Mb/s bandwidth with frame rate 30fps. The recipient side can see the slides as if watch it locally.

Then I used a tool (NetLimiter) to limit the bandwidth usage for Chrome to 10KB/s or even 5KB/s and to my surprise, the resolution didn't drop at all - which means the text is as clear as before - this is what we expect for screen sharing.

But of cause the frame rate decreased a lot to adapt to the low bandwidth, which means the video on the recipient side is not continuous and you may get last steady screen after several seconds.

So I believe they have optimized the VP8 for screen sharing.

Justin maybe you can confirm.

[Mike K]

That's strange same quality with 2.5 Mb/s and 5KB/s. Using the whole available bandwidth is not good. There should be some way of standardized bandwidth control from Java script.

Dne sreda, 23. oktober 2013 22:31:13 UTC+2 je oseba Qiusheng Jiang napisala:

[Mike Vitale]

Any updates on this?  I've experienced spikes in bandwidth as well.  Despite the increased bandwidth the screenshare is still blurry at times.  Are there any plans to add a screen codec to the browser?

[Leighton Carr]

Modern video codecs handle the case of "non changing" pixels as well, so there should be no instance where a lossless codec uses *less* bandwidth than a lossy one.  

[Michael Graves]

I doubt that VP8 has any specific optimizations for screen sharing. Codecs like it are based around a group-of-frames (GOP) where within the group there are I-frames, B-frames and P-frames. An I-frame is a reference frame that contains an entire image. P-frames and B-frames contain only deltas relative to the nearby I frames. The GOP length is fixed.

When transmitting a static image the I frames will still contain a full image, whereas the B/P frames may contain very little data. Thus the bandwidth requirement for such a stream is reduced, but never to zero.

Codecs designed specifically for screen sharing tend to focus more on retaining image quality/detail through the use of simpler, lossless compression techniques.

Michael

[Serge Lachapelle]

On Wed, Mar 12, 2014 at 10:32 PM, Michael Graves <mr.micha...@gmail.com> wrote:

I doubt that VP8 has any specific optimizations for screen sharing. 

IRC there are optimizations and arguments that can be passed in the encoder. I think the folks on webm discuss list can help you get a better understanding of this matter.

/Serge

[Philipp Hancke]

https://github.com/crosswalk-project/chromium-crosswalk/blob/master/remoting/codec/video_encoder_vpx.cc#L108 -- the active map stuff there is probably of interest.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Justin Uberti]

Note also that webrtc doesn't use a GOP for encoding. Is are bad for rate control, and Bs make no sense at all in realtime scenarios.

Overall you will find many applications using VP8 successfully for screen sharing.

[Piyush Ranjan]

Would VP9 be better with loseless mode ? Are we going to have an option of to use VP9 or VP8 when that happens ? Any timelines for VP9 to land ?

[Serge Lachapelle]

The VP9 team is hard at work to adapt the encoder for realtime use. Once that work is done, my guess is that we will start experimenting with it. Hopefully you will too!

/Serge

[Piyush Ranjan]

Awesome!! That would great as I have read somewhere that VP9 has loseless mode. I am working on a screen sharing app. Not very happy with the quality I get on current webrtc. The text looks smudged. 

Also, will this be a switch or an automatic detection (between vp8 and vp9) ? Or that is not decided as of yet. Sorry if this is a dumb question as I do not know if there is codec detection built into webrtc.

[Rob Retter]

Three years later, even using VP9 in Chrome 57, screen shares still look like crap on the receiving end.  This seems to be due to something drastically reducing resolution in order to achieve "efficiency" of transport.

Googling leads to numerous complaints about this phenomenon, but a consistent absence of actual solutions.

Anyone know what's going on, or at least where to look? 

[radioman . lt]

lossless video codec is the key http://www.infognition.com/ScreenPressor/

[Anantha Subramaniam]

The webrtc spec has an option for choosing over resolution or frame rate to be maintained. But it is yet to be implemented in chrome.

https://www.w3.org/TR/webrtc/#dom-rtcdegradationpreference

[Colin Moock]

Four more years later, we are also seeing terrible results with screenshare over WebRTC in our application. In our case, we're seeing a severe drop in bitrate when the user switches from their web cam to a screenshare. The web cam happily transmits at 3.5Mbps. But on the same machine, the screenshare bitrate instantly drops to ~100Kbps. When we switch back to the camera, bitrate returns to 3.5Mbps. This behaviour is 100% reproducible across multiple WebRTC providers for us. See attached for samples of the poor screenshare quality we're seeing. Google Meet also has poor quality screenshare for us. Better than our own attempts in our own application, but still much much worse than Skype or Zoom.

Please note that we are JavaScript web-application developers, and can, therefore, only implement changes available via the browser's JavaScript API. Any insight would be most welcome.

[Eric Davies]

What are the dimensions of that screen you are trying to share?
Do you see the same problem when using Firefox?

On Sat, Jun 12, 2021 at 2:37 AM Colin Moock <co...@moock.org> wrote:

Four more years later, we are also seeing terrible results with screenshare over WebRTC in our application. In our case, we're seeing a severe drop in bitrate when the user switches from their web cam to a screenshare. The web cam happily transmits at 3.5Mbps. But on the same machine, the screenshare bitrate instantly drops to ~100Kbps. When we switch back to the camera, bitrate returns to 3.5Mbps. This behaviour is 100% reproducible across multiple WebRTC providers for us. See attached for samples of the poor screenshare quality we're seeing. Google Meet also has poor quality screenshare for us. Better than our own attempts in our own application, but still much much worse than Skype or Zoom.

Please note that we are JavaScript web-application developers, and can, therefore, only implement changes available via the browser's JavaScript API. Any insight would be most welcome.

On Tuesday, May 30, 2017 at 3:04:43 AM UTC-4 pinga...@gmail.com wrote:

The webrtc spec has an option for choosing over resolution or frame rate to be maintained. But it is yet to be implemented in chrome.

https://www.w3.org/TR/webrtc/#dom-rtcdegradationpreference

On Wednesday, 29 March 2017 23:43:47 UTC+5:30, Rob Retter wrote:

Three years later, even using VP9 in Chrome 57, screen shares still look like crap on the receiving end.  This seems to be due to something drastically reducing resolution in order to achieve "efficiency" of transport.

Googling leads to numerous complaints about this phenomenon, but a consistent absence of actual solutions.

Anyone know what's going on, or at least where to look? 

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/xnC6sJ9o2Yc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7d15abea-8b39-406b-851d-313236ea6219n%40googlegroups.com.

--

Eric Davies

250 595-0639

[Colin Moock]

We did extensive testing this week and have more conclusions to share:

1) The issue does NOT occur in Chrome/Edge/Opera when sharing a screen with the resolution set to anything BELOW 1280x720. I.e., at 800x600 and 1024x786, text looks fine. In Chrome/Edge/Opera, the problem starts at 1280x720. The screenshot shown in my previous message was taken when sharing at 4k.

2) The issue does NOT occur in Firefox. In Firefox, the text is legible even at 4k. At 4k, Windows Firefox has legible text and good framerate, but Mac Firefox has legible text and poor framerate.

3) Setting contentHint to "motion" definitely helps improve the framerate for video content, but does not improve the legibility for text.

4) None of the following WebRTC code tweaks had any effect on text legibility:

a) Setting the x-google-flag:conference flag

b) Setting FPS to an explicit value (e.g., 30)

c) Setting the Codec to VP9 instead of VP8 (though for the record, H264 was worse)

d) Setting maxBitrate to 4000Kbps

e) Setting networkPriority to "high"

f) Setting scaleResolutionDownBy() to lower the resolution 

[Colin Moock]

For anyone else facing this issue:

In Chrome, we were able to workaround the problem by specifying an explicit height and width in the constraints (in our case, 1920x1080 worked fine). Without the constraints, Chrome produces the illegible results shown in my earlier screenshot. With the constraints, the text is legible.

[Philipp Hancke]

without these constraints, what are the resulting videoWidth and videoHeight properties when you attach the video to a track?

There used to a default width/height of 640x480 which is... low compared to common desktop resolutions.

You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/5bb1810f-6449-4f24-a037-7ea641c0e17dn%40googlegroups.com.