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

Reply via email to