Re: [rtcweb] Tim Panton's choices

[Tim Panton <[e-mail]>]

On 28 Dec 2013, at 17:19, Maik Merten <[e-mail]> wrote:

> Am 28.12.2013 17:08, schrieb Tim Panton:
>> 6.
>>    All entities MUST support H.261
>>     1.
>>        Are you in favor of this option [Yes/No/Acceptable]:No
>>     2.
>>        Do you have any objections to this option, if so please
>>        summarize them:
>>        The codec will be unacceptable for a large number of (mobile)
>>        use cases requiring dynamic bandwidth adjustment.
>> 
> 
> Can you elaborate on that argument, which you also apply to H.263 and Theora?
> 
> H.261/H.263/Theora have no fixed increments regarding bitrate and any encoder can scale bandwidth basically at will. IMO bandwidth management is completely within the encoder realm, and implementations can choose to accept new bitrate targets at runtime.

Has any of that been done? Is it exempt from patent attacks? Is there real world experience of how encoders/decoders 
respond to halving the available bandwidth (eg when someone walks between you and the distant wifi ap) during a call?

(I'd note that I think I was the first person to mention using antique codecs to break the logjam - that was back at the IETF in Paris.
Subsequent experiments with VP8 have convinced me that unless a codec natively supports dynamic bandwidth changing
within a call in response to rtcp-fb data then the experience is unacceptable in real world situations). 

> 
> Is there a specific technology you have in mind regarding the term "dynmaic bandwidth adjustment"?

No - just that if you disable rtcp-fb in a VP8 session, you'll have a poor experience - try it in a few wireless environments.

Any codec designed in the TDM pre-allocate-committed-bandwidth days is unlikely to be able to cope 
with the variability of modern 3/4g and wifi networks (IMHO).

I know we are all sitting comfortably on stable Gigabit wired lans doing our testing, but real world usage of webRTC
will be predominantly over unstable wireless links.

Tim.

> 
> 
>> 10.
>>    All entities MUST implement at least two of {VP8, H.264, H.261}
>>     1.
>>        Are you in favor of this option [Yes/No/Acceptable]:No
>>     2.
>>        Do you have any objections to this option, if so please
>>        summarize them:
>>        Along with the objections to 5) and 6) This also brings added
>>        complexity in implementation,
>>        api, user interface and signalling - for a minimal (or zero)
>>        benefit.
> 
> Apart from the complexity of having to implement two codecs, what additional overhead regarding api, user interface (?) and signalling do you refer to, given that codec negotiation will be part of establishing a WebRTC call anyway?
> 
> (The benefit is having no negotiation failure by ensuring non-empty codec intersections)
> 
> Best regards,
> 
> Maik
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb