webrtc constraints

[bryand...@gmail.com]

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?

Thanks

[Adam Roach]

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

Please understand that our WebRTC implementation is still evolving, as
are the WebRTC related specifications, and many features are not yet
implemented. See:

https://hacks.mozilla.org/2013/04/webrtc-update-our-first-implementation-will-be-in-release-soon-welcome-to-the-party-but-please-watch-your-head/

...and...

https://hacks.mozilla.org/2013/06/webrtc-comes-to-firefox/

/a


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863

[bryand...@gmail.com]

Thanks, Adam, for the info. I understand that it is a work in progress.

fyi --
b=AS:xxx works in Chrome at the media level to set the desired opus / vp8
bandwidth.

[Randell Jesup]

On 7/3/2013 7:57 PM, Adam Roach wrote:
> On 7/3/13 18:48, bryand...@gmail.com 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

[bryand...@gmail.com]

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 <rje...@mozilla.com> wrote:

> On 7/3/2013 7:57 PM, Adam Roach wrote:
>
>> On 7/3/13 18:48, bryand...@gmail.com wrote:
>>
>>> FF 22 does not seem to honor the video constraints passed to
>>> getUserMedia:
>>>
>>> getUserMedia(

>>> {audio:true,video:{mandatory:{**maxWidth:320,maxHeight:240}}}

> ______________________________**_________________
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-media<https://lists.mozilla.org/listinfo/dev-media>
>

[Adam Roach]

On 7/5/13 01:36, Randell Jesup wrote:
> 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

You are correct -- I had identified that b= was defined for declarative
SDP, and didn't find the string "b=" in RFC 3264, so I assumed it meant
the same thing (i.e., the bandwidth to be sent). By searching for
"bandwidth" in 3264, I see that it reverses the sense of "b=" for
negotiated SDP.

That being the case, we probably ought to open another bug for plumbing
this into the media engine, similar to what we're doing in Bug 881935
right now.

[Philipp]

Is there any progress in bandwidth control in firefox lately?

[Jan-Ivar Bruaroey]

Given the subject, are you looking for a bandwidth setting/constraint on
RTCPeerConnection or just a working b=?

I believe Chrome has something like the former but it is not in the spec
AFAIK, so I don't know what the plan is for that. Maybe others here can
comment on that.

The width/height/framerate gUM constraints are my next item after this
work week.

..: Jan-Ivar :.

[Philipp Seeser]

I can see SDP_BW_MODIFIER_AS<http://mxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/sipcc/include/ccsdp.h#164>
implementation
however it is not used yet.

sdp.replace( /a=sendrecv\r\n/g , 'a=sendrecv\r\nb=AS:20\r\n')

I can see a visible affect on chrome's outgoing stream; however Firefox's
outgoing stream uses system's available bandwidth instead of application
controlled bandwidth.


2014-02-10 Jan-Ivar Bruaroey <j...@mozilla.com>:

> Given the subject, are you looking for a bandwidth setting/constraint on
> RTCPeerConnection or just a working b=?
>
> I believe Chrome has something like the former but it is not in the spec
> AFAIK, so I don't know what the plan is for that. Maybe others here can
> comment on that.
>
> The width/height/framerate gUM constraints are my next item after this
> work week.
>
> ..: Jan-Ivar :.
>
> On 2/8/14 12:10 PM, Philipp wrote:
>

[Lorenzo Miniero]

On a related subject, does Firefox handle REMB messages that tell it what the available bandwidth on the peer side should be? I can see Firefox does not generate any at the moment, but knowing it can handle them would be good to address the requirement for the time being.

Lorenzo

[b...@terminverpennt.de]

Any progress on bandwidth/webrtc constraints control in firefox yet?