Randell, I have web conference application. In my use case everything is hub-and-spoke with a server and groups of receivers, as opposed to peer to peer.
By specifying a low receive bandwidth, I can be fairly certain that users will be able to consume the presentation, even those half way around the world or on poor connections. I do not wish to rely on automatic feedback for large groups of receivers. Also, with a low and predictable bandwidth, I can do capacity planning for servers based on number of receivers. FF starts streaming video at 500kbps, which is >5x too high for my purposes. I don't want or need VGA+ or high frame rates. I need a small talking head, <= 15fps, <= 100kbps. When I tell Chrome to limit video bw to 100kbps, it actually sends at around 60kbps, and the quality is perfect for what my application requires. At 500kbps video, + audio and overhead, I can stream to fewer than 2000 users on a gigabit connection, and I need that number to be much higher. b=AS: might not be the correct way, but it is the first bandwidth control that appeared in Chrome, so that is what I used. Thanks On Thu, Jul 4, 2013 at 11:36 PM, Randell Jesup <[email protected]> wrote: > On 7/3/2013 7:57 PM, Adam Roach wrote: > >> On 7/3/13 18:48, [email protected] wrote: >> >>> FF 22 does not seem to honor the video constraints passed to >>> getUserMedia: >>> >>> getUserMedia( >>> {audio:true,video:{mandatory:{**maxWidth:320,maxHeight:240}}} >>> ,gotStream >>> ,noStream); >>> >>> Also, the b=AS:xxx that I put into the offer SDP for audio and video >>> seems >>> to have no effect at limiting bandwidth, >>> >>> Is there any way to limit resolution, frame rate and bandwidth in >>> Firefox's >>> WebRTC? >>> >> >> Not yet. >> >> I also don't think the "b=" line in SDP works the way you're envisioning >> here. When this kind of control becomes available, it will be signaled >> using a=fmtp: on a per-format basis (at least initially). >> > > In this case, I think Bryan is probably correct: b=AS:XXX or b=TIAS:XXXX > at the media level specifies you'd like that to be the limit for > *receiving* data on that m-line from one source, or at the session level as > b=CT:xxxx for a limit on all m-lines together from all sources. (b=as/tias > can also be used at the session level, and b=ct at the media level, but > those uses are a bit more esoteric in principle, though if there's only one > m-line it really doesn't matter). > > Currently, Firefox does not look at b= values. > > > However, you should not have to work directly with the SDP -- hopefully, >> we'll be adding API calls to the standard to accommodate your use cases. >> > > Right. SDP has many options, and no SDP endpoints implement all of them > (and there are consistency/interop issues surrounding many of them as well, > making them dangerous to use in heterogeneous environments). Support for > b= is not unreasonable, but is also not high priority, as JS applications > rarely will have a good idea as to when bandwidth the other side should be > limited to. In theory the browser might know something about the network > connection speed, but this is fraught with uncertainty; it's generally > better to let the automatic systems for bandwidth adaptation (and CPU use > monitoring) take control. > > Bryan, if you have use-cases where it's important for webrtc endpoints to > be able to specify the *receive* bandwidth, please let us (the IETF rtcweb > and W3 WebRTC working groups) know since these would impact the API. If > you have use-cases where it's important that WebRTC endpoints *respect* an > incoming b= value, please also let us know. > > Thanks! > Randell Jesup, Mozilla > > ______________________________**_________________ > dev-media mailing list > [email protected] > https://lists.mozilla.org/**listinfo/dev-media<https://lists.mozilla.org/listinfo/dev-media> > _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
