Re: [rtcweb] Video codec selection - way forward

[Maik Merten <[e-mail]>]

Am 20.11.2013 04:27, schrieb Bernard Aboba:
> Maik said:
>
>  > - implementing the codec of "the other codec camp" is more desirable
>  > - the end-users will appreciate spuriously failing video calls
>
> [BA] The above are not the only choices, because it is not necessary to
> "implement the codec of the other codec camp" in order to provide
> support for it.  The Cisco offer of an H.264 encoder/decoder is only one
> example.

I meant "implementing" as in "implementing and deploying support for".

Cisco's offer, while certainly useful in some (or even many) application 
contexts, cannot cover all relevant deployment scenarios. This not only 
concerns WebRTC implementation providers, but also users (for instance, 
what licensing status do machines have that are recovered from disk 
images that happen to include the binary blob implementing H.264?).


> So really, the choice is more between "support codec extensibility and
> allow 'the other codec camp' to take risks they are comfortable with"
> and "implement an inferior codec no one wants".

Without a fallback codec there will be negotiation failure in ways that 
are out of control of the affected users. I think this is undesirable 
for all involved parties. Implementing support for an "IPR-safe", 
unsophisticated, well-understood, albeit sadly low-performing codec to 
me sounds like a manageable requirement for implementers to guarantee a 
minimal level of video interoperability. It's for sure an inconvenience, 
but so is firewall traversal.


Maik