RFE: Bandwidth should ramp up faster

[cowwoc]

Hi,

I believe that the Chrome implementation of WebRTC should be able
to ramp up to 1080p, 30fps within 3-10 seconds. Currently it takes 1-5
minutes. Should I file a bug report for this, or does the topic warrant
further discussion?

Thank you,
Gili

[Vikas]

Hi,

Can you clarify further, are you saying that you call GetUserMedia on the send side with 1080p, 30fps but on the receive side the resolution takes 1-5 minutes to show up due to bandwidth not adapting quickly?

/Vikas

[Leighton Carr]

Not to put words into Gili's mouth, but he's probably talking about how long it takes for the bitrate to ramp up to acceptable levels for 1080p - especially over a LAN or fast network.  This is a pretty standard ramp up graph for 1080p:

http://i.imgur.com/UmIrbu0.png

Ideally we need to be able to set min and max bitrate in the offer, in the same way we can set resolution, and have WebRTC start at the minimum bitrate specified by the developer.  

[Gili T.]

Correct. To provide more context:

1. There is resistance on the WebRTC mailing list for adding a minimum bandwidth hint due to fear of network congestion.
2. However, there is no dispute that WebRTC implementations (such as Chrome) need to ramp up *a lot* faster than they currently do.

As I mentioned in the webrtc mailing list: if you start downloading a large file from DropBox it takes ~3 seconds for the bandwidth to ramp up to your maximum. If you repeat the same experiment with WebRTC, it'll take Chrome 1-5 minutes to discover the available bandwidth. 5 minutes vs 3 seconds... Clearly, there is room for improvement and this isn't a matter of network congestion.

I filed https://code.google.com/p/chromium/issues/detail?id=297163 to track this issue.

Gili

[Leighton Carr]

Three second ramp up would solve a lot of issues with regards to the minimum bitrate, but I hope they are still discussing maximum bitrate in the API.  We recently had a WebRTC video going over a satellite link and it would have been nice to do the bandwidth control as part of the offer.

That said, I'm not entirely convinced that not exposing min bitrate at all is a great idea.  This should be left up to the developer, and (obviously) applications that handle it well will be preferred over those that do not.  Limiting the flexibility of the API is only going to limit the potential applications of this technology.

[cowwoc]

    If WebRTC was able to ramp up instantaneously why would you need to specify a minimum bandwidth? What is the meaning of minBandwidth if not as a mechanism to ramp up faster? I mean, do you have another use-case?

Gili

--
 
---
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/u9JeI05Bskk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Leighton Carr]

Well 3 seconds isn't instantaneously and we're looking at a pretty wide variety of applications, from remote instruction to remote repair.  One of the use cases that I was asked about not 2 hours ago was making sure that the video quality didn't drop below a certain threshold without being able to flag to the end user.  You could do this with getStats() (I assume?), but it certainly isn't hard for me to imagine situations where people would want to drop frames instead of encoding quality.

Either way, the codec is more than capable of doing it, so why not expose it?  If the working group is worried about inexperienced developers saturating network bandwidth they should take comfort in the fact that there are a lot of 3rd party wrappers coming out for WebRTC already.

[cowwoc]

Leighton,

    The argument I've been given is that browser vendors adhere to IETF guidelines and the latter refuses to endorse any algorithm that risks "saturating the internet". Meaning, they're coding this limitation at the protocol level so no matter what 3rd-party wrappers you use you'll never be able to workaround this limit.

    Ensuring minimum video quality is tricky, because still video uses a lot less bandwidth than video with a lot of motion... and it's not clear how you define the quality of any given video (it varies by codec). I get your point and I want the same thing (some mechanism to specify the minimum acceptable quality level) but the community hasn't figured out how to represent this as part the API. I am afraid they will omit it altogether.

    You brought up a second use-case where you prioritize encoding quality in exchange for a lower frame rate (i.e. drop frames). This use-case is covered by this proposal: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20819

Gili

[Leighton Carr]

Well with regards to the implementation of WebRTC, it would be pretty easy to have internal caps on the "minBitrate" to prevent a rogue application saturating the internet.  But I take your point on the standards front - it's fairly difficult to define the mechanism without some risk it will be implemented poorly.  

The prioritising API would also be really handy - hope that one gets in.  It's interesting that it covers data channels as well, which is another bandwidth concern.  One major use case we have is synchronising data with video - do you know if they are considering this, and how bandwidth might affect it?

[cowwoc]

On 23/09/2013 9:28 PM, Leighton Carr wrote:

Well with regards to the implementation of WebRTC, it would be pretty easy to have internal caps on the "minBitrate" to prevent a rogue application saturating the internet.  But I take your point on the standards front - it's fairly difficult to define the mechanism without some risk it will be implemented poorly.  

The prioritising API would also be really handy - hope that one gets in.  It's interesting that it covers data channels as well, which is another bandwidth concern.  One major use case we have is synchronising data with video - do you know if they are considering this, and how bandwidth might affect it?

    I'm not sure. I've mostly ignored all discussion of DataChannel myself. It's a very interesting technology but I don't have an immediate use for it.

    I recommend joining public...@w3.org and throwing in your voice.

Gili

[Jason Wood]

Hi,

The ramp-up is the major issue preventing us from using Web-RTC in a production environment.

Our use-case is to use a tablet as a second-screen using chrome for android. The video server is a graphics renderer using native/c++ libjingle to stream the video, we only send video, no audio, and the tablet does not send any video/audio back.

Low latency is vital to us, as we want to control the renderer from the tablet.

Currently, the issues we see with libjingle are :

  * It takes several minutes for the video stream to reach the maximum bandwidth.

  * If the video that we send changes drastically, for example cutting from one camera to another, or if we pause our video (we send the same frame over and over again when the video is paused) and the unpause it, the bandwidth drops to the minimum again and the ramp up starts again.

We have direct control over our network and can guarantee that the only things on it are the renderer, the wireless router and the tablets connected to it, so in our sitaution, we want to be able to tell libjingle to start at a high bitrate and stay there.

There are some constants in webrtcvideoengine.cc in the libjingle code, kMinVideoBitrate, kMaxVideoBitrate and kStartVideoBitrate that we have changed and recompiled to try and make it stay within the bandwidths that we want, but we still have some issues, and would very much prefer to be using an official mechanism to achieve the same!

Cheers,

Jason

--
 
---
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.

[Gili T.]

Hi Jason,

This issue is covered by https://code.google.com/p/chromium/issues/detail?id=297163

This is precisely the kind of behavior I have seen and have reported above. Please help us by providing the debugging information the committers have asked for. I will try to do the same later on this week.

Gili

[Jason Wood]

Hi Gili,

I am updating webrtc to the latest version in our software, and then will test and provide the wireshark logs to the bug report as requested.

Cheers,

Jason