[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 09:12:32 CET 2011 

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)

On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <
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]
> *Sent:* den 21 januari 2011 08:46
> *To:* Henry Sinnreich
> *Cc:* Stefan Håkansson LK; Stephen Botzko; Cullen Jennings;
> 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> 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
> *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>  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>
> 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
> >>  [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
> >>  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 listRTC-Web at alvestrand.nohttp://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/3dc4d257/attachment.html>

More information about the RTC-Web mailing list