[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