Re: [rtcweb] Tim Panton's choices

[Stephan Wenger <[e-mail]>]

Tim,

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

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.

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

>
>(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
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb