W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2015

Re: I have created a PR for RtpEncodingParameters.maxBitrate

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 20 Jul 2015 20:00:40 +1000
Message-ID: <CAHp8n2n2M=sQkC1uip69y4MoMM1muP1dB7biXmFjpmTkVBh9sw@mail.gmail.com>
To: Luis López Fernández <luis.lopez@urjc.es>
Cc: public-webrtc <public-webrtc@w3.org>, Randell Jesup <randell-ietf@jesup.org>
Btw: I use b:as too to set a threshold, but it's a rather arbitrary number
determined by trial and error about what looks still good, but releaves the
network. I'm not arguing that we don't need it - I'm saying it's often
suboptimal.

Best Regards,
Silvia.
On 20 Jul 2015 7:44 pm, "Luis López Fernández" <luis.lopez@urjc.es> wrote:

> If you allow me to see it from other (developer) perspective, there is a
> relevant number of WebRTC applications using MCU or SFU for group
> communications and one-to-many distributions. In such applications, setting
> maxBitrate in absolute terms makes possible to control and plan better the
> scalability of the infrastructure. For example, feedback from developers in
> the Kurento mailing list shows a lot of people mangling the SDP for adding
>  b=as:max-bw lines in order to have this feature. IMO it would be a plus to
> enable it directly at the API level in absolute terms, which by the way is
> compatible with enabling also setting it relatively.
>
> Best.
>
> L.
>
> El 19/07/2015, a las 05:07, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> escribió:
>
> As a developer, I would really like to see controls that are relative
> to these boundaries, not absolute numbers. E.g. I'd like to tell each
> outgoing/incoming video stream to use no more than 25% of my available
> bandwidth - which would then adapt to the available bandwidth (looks
> like RTP would then also need to negotiate the minimum of the two).
> Then, e.g., the data channel should use no more than 40% of my
> available bandwidth - since it's bursty, it can take a bit more.
>
>
>
Received on Monday, 20 July 2015 10:01:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:08 UTC