[RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)
Justin Uberti
juberti at google.com
Fri Jan 21 20:43:37 CET 2011
TFRC isn't perfect, but it seems to work pretty well in practice. 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110121/f902ce11/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/20110121/f902ce11/attachment-0001.gif>
More information about the RTC-Web
mailing list