Re: [rtcweb] Tim Panton's choices

[Maik Merten <[e-mail]>]

I'm not Stephan, but my two cents...

Am 30.12.2013 17:00, schrieb Tim Panton:
> So If I understand that correctly:
> 1) rate control on the older codecs is possible.

Yes.

> 2) rate control is typically separated from the codec itself

Yes.

> 3) rate control is heavily patented

I have no reason to doubt Stephan's expertise there.

> 4) a modern H261 implementation would (mostly) use the same rate control techniques as H264 or VP8

Not necessarily, given how long rate control has been studied and 
implemented.


> 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.

 From my POV: The "same IPR risks" is an overestimation. Rate control is 
one aspect of encoder technology that is not essential to the definition 
of the video format itself. VP8 and H.264 bring IPR risks that are 
inherent to the respective formats ("standard-essential patents"). In 
the area of rate control there always should be work-arounds (in worst 
case implement a rate-control scheme from the early 1990ies).


> 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?

If a channel requires fixed increments, the usual way of operation is to 
encode content with a bitrate target slightly below that, and fill out 
the remaining bandwidth ("padding with zeros"). The padding is there to 
deal with the inherent bitrate variability of the video formats. So 
getting those fixed steps actually is additional work.

No codec brought up so far operates in fixed steps as normal mode of 
operation - in fact, the discussed codecs are of variable bitrate in 
nature, due to the nature of their entropy coding backends.