[RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)
Harald Alvestrand
harald at alvestrand.no
Fri Jan 21 08:46:22 CET 2011
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]
> *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] 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 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/50680d52/attachment-0001.html>
More information about the RTC-Web
mailing list