[RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)
Justin Uberti
juberti at google.com
Sun Jan 23 06:41:20 CET 2011
Google Video Chat uses a TFRC-based algorithm for rate control.
On Sat, Jan 22, 2011 at 6:18 AM, Saverio Mascolo
<saverio.mascolo at gmail.com>wrote:
>
>
> On Fri, Jan 21, 2011 at 8:43 PM, Justin Uberti <juberti at google.com> wrote:
>
>> TFRC isn't perfect, but it seems to work pretty well in practice.
>
>
> in practice where????
>
> -sm
>
> The RTP extension header overhead of 12 bytes per packet is fairly nominal
>> (1%) at today's video bitrates, as is the cost of the RTCP feedback message.
>>
>> I'm not aware of any other standards-track bandwidth estimation algorithms
>> designed to work with RTP/UDP.
>>
>> On Fri, Jan 21, 2011 at 9:46 AM, <tom_harper at logitech.com> wrote:
>>
>>> It seems to me neither avpf or tfrc is fully perfect- on the whole tfrc
>>> seems to be better than avpf in terms of constant measurement of the
>>> connection-
>>>
>>> tfrc seems scary/impractical at low latencies due to the following:
>>> "The TFRC requirements of receiving feedback once per RTT can at times
>>> conflict with the AVP RTCP bandwidth constraints, particularly at
>>> small RTTs of 20 ms or less"
>>> and the fact that it has to be attached as an extension header to every
>>> data packet seems like more overhead than is needed, but others opinions may
>>> differ on this.
>>>
>>> We support avpf as defined 5104/4585, but prefer not to use it as in some
>>> scenarios we have run into the rtcp bandwidth cap- and then you get no
>>> feedback at all in a timely manner.
>>>
>>> Are there any other inband schemes that are up in rfc at this point?
>>>
>>> Tom
>>>
>>>
>>>
>>> [image: Inactive hide details for Stefan H嶡ansson LK ---01/21/2011
>>> 12:38:33 AM---Isn't it so that with the AVPF profile you can actua]Stefan
>>> H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF
>>> profile you can actually sent RTCP when there is a need (even if a tr
>>>
>>> From: Stefan H嶡ansson LK <stefan.lk.hakansson at ericsson.com>
>>> To: Justin Uberti <juberti at google.com>
>>> Cc: Cullen Jennings <fluffy at cisco.com>, DISPATCH list <dispatch at ietf.org>,
>>> Henry Sinnreich <henry.sinnreich at gmail.com>, Harald Alvestrand <
>>> harald at alvestrand.no>, "rtc-web at alvestrand.no" <rtc-web at alvestrand.no>,
>>> Stephen Botzko <stephen.botzko at gmail.com>
>>> Date: 01/21/2011 12:38 AM
>>>
>>> Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The
>>> charter formerly know as RTC-WEB take 3)
>>> Sent by: rtc-web-bounces at alvestrand.no
>>> ------------------------------
>>>
>>>
>>>
>>> Isn't it so that with the AVPF profile you can actually sent RTCP when
>>> there is a need (even if a transmission is not due)? This way you can
>>> actually react fast.
>>>
>>> ------------------------------
>>> *From:* Justin Uberti [mailto:juberti at google.com <juberti at google.com>] *
>>> Sent:* den 21 januari 2011 09:13*
>>> To:* Stefan Håkansson LK*
>>> Cc:* Harald Alvestrand; Henry Sinnreich; Cullen Jennings;
>>> rtc-web at alvestrand.no; DISPATCH list; Stephen Botzko*
>>> Subject:* Re: [RTW] Rate control and codec adaption (Re: [dispatch] The
>>> charter formerly know as RTC-WEB take 3)
>>>
>>> RTCP typically isn't sent frequently enough to allow for real-time
>>> adjustments in bitrate. TFRC provides a nice mechanism for controlling
>>> bitrate in real-time, but the work to apply TFRC to RTP has not yet been
>>> codified into a standard.
>>>
>>> There was a draft but it has been abandonded (*
>>> http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10*<http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10>
>>> )
>>>
>>> On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <*
>>> stefan.lk.hakansson at ericsson.com* <stefan.lk.hakansson at ericsson.com>>
>>> wrote:
>>>
>>> My view: we are discussing a problem already solved! The common
>>> procedure would be to use info in the RTCP reports from the receiving end to
>>> change the transmitted bit rate (if change is required).
>>>
>>> ------------------------------
>>> *From:* Harald Alvestrand [mailto:*harald at alvestrand.no*<harald at alvestrand.no>]
>>> *
>>> Sent:* den 21 januari 2011 08:46*
>>> To:* Henry Sinnreich*
>>> Cc:* Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; *
>>> rtc-web at alvestrand.no* <rtc-web at alvestrand.no>; DISPATCH list*
>>> Subject:* Rate control and codec adaption (Re: [RTW] [dispatch] The
>>> charter formerly know as RTC-WEB take 3)
>>>
>>> On 01/21/2011 12:06 AM, Henry Sinnreich wrote:
>>> >Minor comment: I think all codecs that have been discussed
>>> (except for G.711) are adaptive in the sense that their bitrate can be
>>> adapted.
>>>
>>> It is not clear to me how to avoid the codec adaptation
>>> mechanism fighting the rate control mechanism, without some guidance in the
>>> standard for developers.
>>> Can you explain?
>>> Changing the subject to content of thread....
>>>
>>> are we reducing to a previously solved problem, or to a previously
>>> unsolved problem?
>>> I don't see how this problem actually differs from the one that
>>> people will have when operating RTP under TFRC
>>> (draft-ietf-avt-tfrc-profile-10).
>>>
>>> Thanks, Henry
>>>
>>>
>>> On 1/20/11 2:02 PM, "Stefan Håkansson LK" <*
>>> stefan.lk.hakansson at ericsson.com*<http://stefan.lk.hakansson@ericsson.com/>>
>>> wrote:
>>> Minor comment: I think all codecs that have been discussed
>>> (except for G.711) are adaptive in the sense that their bitrate can be
>>> adapted.
>>>
>>> Br,
>>> Stefan
>>>
>>>
>>> ------------------------------
>>> *From:* Stephen Botzko [*
>>> mailto:stephen.botzko at gmail.com*<stephen.botzko at gmail.com>]
>>> *
>>> Sent:* den 20 januari 2011 16:45*
>>> To:* Henry Sinnreich*
>>> Cc:* Stefan Håkansson LK; Cullen Jennings; DISPATCH
>>> list; *rtc-web at alvestrand.no*<http://rtc-web@alvestrand.no/>
>>> *
>>> Subject:* Re: [dispatch] The charter formerly know
>>> as RTC-WEB take 3
>>>
>>>
>>> >>>
>>> How does this fit with adaptive codecs?
>>> >>>
>>> Just because some codecs can adapt doesn't mean
>>> rate adaptation/congestion control should be left out of the scope. I think
>>> it needs to be considered.
>>>
>>> >>>
>>> Hint: codec selection matters, is actually critical
>>> to this effort.
>>> >>>
>>> Codec selection does matter, but I am not convinced
>>> that mandatory codecs need to be in the RFCs. I believe market forces are
>>> sufficient - SIP itself is one proof point.
>>>
>>> Stephen Botzko
>>>
>>>
>>>
>>> On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <
>>> *henry.sinnreich at gmail.com*<http://henry.sinnreich@gmail.com/>>
>>> wrote:
>>> Hi Stefan,
>>>
>>>
>>> > 2. The second one is about rate
>>> adaptation/congestion control. It is not
>>> > mentioned at all. I don't know if it is
>>> needed, perhaps it is enough that
>>> > RFC3550 (that is already pointed at) has a
>>> section about it, but I wanted to
>>> > highlight it.
>>>
>>> How does this fit with adaptive codecs?
>>> Hint: codec selection matters, is actually
>>> critical to this effort.
>>>
>>> Thanks, Henry
>>>
>>>
>>> On 1/20/11 3:52 AM, "Stefan Håkansson LK" <*
>>> stefan.lk.hakansson at ericsson.com*<http://stefan.lk.hakansson@ericsson.com/>
>>> >
>>> wrote:
>>>
>>>
>>>
>>>
>>> > Hi Cullen,
>>> >
>>> > two comments:
>>> >
>>> > 1. As requirements on the API are
>>> explicitly described, I thinke that there
>>> > should be a comment that the API must
>>> support media format negotiation.
>>> > Proposal: "The API must enable media format
>>> negotiation and application
>>> > influence over media format selection".
>>> >
>>> > 2. The second one is about rate
>>> adaptation/congestion control. It is not
>>> > mentioned at all. I don't know if it is
>>> needed, perhaps it is enough that
>>> > RFC3550 (that is already pointed at) has a
>>> section about it, but I wanted to
>>> > highlight it.
>>> >
>>> > Br,
>>> > Stefan
>>> >
>>> >> -----Original Message-----
>>> >> From: *dispatch-bounces at ietf.org*<http://dispatch-bounces@ietf.org/>
>>> >> [*mailto:dispatch-bounces at ietf.org*<dispatch-bounces at ietf.org>]
>>> On Behalf Of Cullen Jennings
>>> >> Sent: den 18 januari 2011 05:59
>>> >> To: DISPATCH list
>>> >> Cc: *rtc-web at alvestrand.no*<http://rtc-web@alvestrand.no/>
>>> >> Subject: [dispatch] The charter formerly
>>> know as RTC-WEB take 3
>>> >>
>>> >>
>>> >> In my dispatch co-chair role, I tried to
>>> take all the
>>> >> comments I had seen on the list about this
>>> charter and see if
>>> >> I could address them in a new version of
>>> the charter. I
>>> >> probably messed up in some places. There
>>> were some
>>> >> conversation that did not seem to be
>>> converging so I did not
>>> >> make any changes for theses. Have a read
>>> and if you think
>>> >> something needs to be changed, propose
>>> text changes along
>>> >> with the reasons why and we will keep the
>>> evolving this charter.
>>> >>
>>> >> Thanks
>>> >> Cullen
>>> >>
>>> >>
>>> --------------------------------------------------------------
>>> >> --------------------
>>> >>
>>> >> Version: 3
>>> >>
>>> >> Possible Names:
>>> >>
>>> >> RTCWEB
>>> >> WEBRTC
>>> >> STORM: Standardized Transport Oriented for
>>> Realtime Media
>>> >> BURN: Browsers Using Realtime Media
>>> >> WAVE: Web And Voice/Video Enablement
>>> >> WAVVE: Web And Voice Video Enablement
>>> >> REALTIME
>>> >> WEBCOMM
>>> >> WREALTIME
>>> >> WEBTIME
>>> >> WEBFLOWS
>>> >> BRAVO Browser Realtime Audio and VideO
>>> >> COBWEB COmmuication Between WEBclients
>>> >> WHEELTIME
>>> >>
>>> >>
>>> >>
>>> >> Body:
>>> >>
>>> >> Many implementations have been made that
>>> use a Web browser to
>>> >> support direct, interactive
>>> communications, including voice,
>>> >> video, collaboration, and gaming. In these
>>> implementations,
>>> >> the web server acts as the signaling path
>>> between these
>>> >> applications, using locally significant
>>> identifiers to set up
>>> >> the association. Up till now, such
>>> applications have
>>> >> typically required the installation of
>>> plugins or
>>> >> non-standard browser extensions. There is
>>> a desire to
>>> >> standardize this functionality, so that
>>> this type of
>>> >> application can be run in any compatible
>>> browser and allow
>>> >> for high-quality real-time communications
>>> experiences within
>>> >> the browser.
>>> >>
>>> >> Traditionally, the W3C has defined API and
>>> markup languages
>>> >> such as HTML that work in conjunction with
>>> with the IETF over
>>> >> the wire protocols such as HTTP to allow
>>> web browsers to
>>> >> display media that does not have real time
>>> interactive
>>> >> constraints with another human.
>>> >>
>>> >> The W3C and IETF plan to collaborate
>>> together in their
>>> >> traditional way to meet the evolving needs
>>> of browsers.
>>> >> Specifically the IETF will provide a set
>>> of on the wire
>>> >> protocols, including RTP, to meet the
>>> needs on interactive
>>> >> communications, and the W3C will define
>>> the API and markup to
>>> >> allow web application developers to
>>> control the on the wire
>>> >> protocols. This will allow application
>>> developers to write
>>> >> applications that run in a browser and
>>> facilitate interactive
>>> >> communications between users for voice and
>>> video
>>> >> communications, collaboration, and gaming.
>>> >>
>>> >> This working group will select and define
>>> a minimal set of
>>> >> protocols that will enable browsers to:
>>> >>
>>> >> * have interactive real time voice and
>>> video pairwise be
>>>
>>> _______________________________________________
>>> RTC-Web mailing list
>>> *RTC-Web at alvestrand.no* <RTC-Web at alvestrand.no>
>>> *http://www.alvestrand.no/mailman/listinfo/rtc-web*<http://www.alvestrand.no/mailman/listinfo/rtc-web>
>>>
>>>
>>> _______________________________________________
>>> RTC-Web mailing list*
>>> **RTC-Web at alvestrand.no* <RTC-Web at alvestrand.no>*
>>> **http://www.alvestrand.no/mailman/listinfo/rtc-web*<http://www.alvestrand.no/mailman/listinfo/rtc-web>
>>>
>>> _______________________________________________
>>> RTC-Web mailing list
>>> RTC-Web at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>
>>>
>>> _______________________________________________
>>> RTC-Web mailing list
>>> RTC-Web at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>
>>>
>>
>> _______________________________________________
>> RTC-Web mailing list
>> RTC-Web at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>
>>
>
>
> --
> Prof. Saverio Mascolo
> Dipartimento di Elettrotecnica ed Elettronica
> Politecnico di Bari
> Via Orabona 4, 70125 Bari Italy
> Tel. +39 080 5963621 <tel:+390805963621>
> Fax. +39 080 5963410 <tel:+390805963410>
> email:mascolo at poliba.it <email%3Amascolo at poliba.it>
>
> http://c3lab.poliba.it
>
>
> =================================
> This message may contain confidential and/or legally privileged
> information.
> If you are not the intended recipient of the message, please destroy it.
> Any unauthorized dissemination, distribution, or copying of the material
> in
> this message, and any attachments to the message, is strictly forbidden.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110122/3b7532b4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110122/3b7532b4/attachment-0001.gif>
More information about the RTC-Web
mailing list