Re: [rtcweb] Tim Panton's choices

[Tim Panton <[e-mail]>]

On 30 Dec 2013, at 15:47, Stephan Wenger <[e-mail]> wrote:

> Tim,
> 
> I believe your questions below have been answered before, but allow me to
> add more redundancy.
> 

How apposite :-) - Must be some lossy connection between me and the discussion, or 
perhaps I temporarily didn't have the bandwidth to keep up !

> Stephan
> 
> On 12/30/13, 6:05 AM, "Tim Panton" <[e-mail]> wrote:
> 
>> 
>> 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?
> 
> It¹s bread and butter for encoder developers since at least 1990.
> 
>> Is it exempt from patent attacks?
> 
> I don¹t know what ³exempt from patent attacks² means, but I will note that
> rate control mechanisms are among the most heavily patented encoder
> mechanisms.  For two reasons: every real-world encoder needs some form of
> rate control (to adapt to application requirements that include network
> condition dictated bandwidth as well as user dictated bandwidth), and
> features of rate control determine to a significant extent the performance
> of an overall system over variable speed networks such as the
> Internet--and are, therefore, a critical product differentiator.
> Note that the vast majority of rate control patents are written
> independently of the codec technology in use.  The possible exception are
> rate control mechanisms that cover somewhat exotic codec technologies:
> scalability, SI/SP pictures, and the like.  For the purpose of the
> discussion at hand, you can lump together into the same risk category any
> of the codecs under discussion with the exception of MJPEG.  Note also
> that many modern rate control algorithms work on older codecs, and vice
> versa.  Design-around is sometimes an option once a patent has been
> asserted--normally at the cost of some performance.
> 

So If I understand that correctly:
1) rate control on the older codecs is possible.
2) rate control is typically separated from the codec itself
3) rate control is heavily patented
4) a modern H261 implementation would (mostly) use the same rate control techniques as H264 or VP8 

which leaves me wondering if selecting H261 wouldn't mean we retain many of the same IPR risks of newer codecs
but without a licensing authority to go to for fixes/workarounds (or a technical or legal nature). And still
have a significantly worse visual experience at a given bandwidth than for a modern codec.

Seems like the worst of all worlds to me - hopefully I misunderstood.

>> 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?
> 
> Halving the bandwidth is trivial for H.26x and VPx.  The dynamic range of
> bandwidth for any of the codecs under discussion (minus MJPEG perhaps) is
> several orders of magnitude.  Yes, there is such real-world experience and
> has been since at least 1990 (ISDN MCU implementations, also academic
> work).

Surely with ISDN the steps were quantized at 64kbps? 

Tim.