Re: [dispatch] [RTW] Rate control and codec adaption (Re: The charter formerly know as RTC-WEB take 3)

[Stefan Håkansson LK <[e-mail]>]

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:[e-mail]]
Sent: den 21 januari 2011 09:13
To: Stefan Håkansson LK
Cc: Harald Alvestrand; Henry Sinnreich; Cullen Jennings; [e-mail]; 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)

On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
Sent: den 21 januari 2011 08:46
To: Henry Sinnreich
Cc: Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; [e-mail]<mailto:[e-mail]>; 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" <[e-mail]<http://[e-mail]>> 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:[e-mail]]
Sent: den 20 januari 2011  16:45
To: Henry Sinnreich
Cc: Stefan Håkansson LK; Cullen  Jennings; DISPATCH list; [e-mail]<http://[e-mail]>
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 <[e-mail]<http://[e-mail]>>  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" <[e-mail]<http://[e-mail]>>
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: [e-mail]<http://[e-mail]>
>>  [mailto:[e-mail]] On  Behalf Of Cullen Jennings
>> Sent: den 18 januari 2011  05:59
>> To: DISPATCH list
>> Cc: [e-mail]<http://[e-mail]>
>>  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
[e-mail]<mailto:[e-mail]>
http://www.alvestrand.no/mailman/listinfo/rtc-web



_______________________________________________
RTC-Web mailing list
[e-mail]<mailto:[e-mail]>
http://www.alvestrand.no/mailman/listinfo/rtc-web