[rtcweb] Stephane Cazeaux's choices (Was: Straw Poll on Video Codec Alternatives)

[Peter Dunkley <[e-mail]>]

and the same applies to other's who have said YES to only one option and
made statements like this...


> 3.    All entities MUST support both H.264 and VP8
> .      Are you in favor of this option [Yes/No/Acceptable]:
>
> *NO*a.    Do you have any objections to this option, if so please
> summarize them:
>
> *Having two codecs brings no benefits to any use case (pure webrtc or
> compatibility with existing services) compared to H.264 only. On the
> contrary, it adds costs and risks to all devices that would need to support
> both codecs.*
>
>
Surely it would be more accurate to say "Having two codecs brings no
benefits to any use case *that I care about *(pure webrtc or compatibility
with existing services) compared to H.264 only."

Given the near infinite number of possible use cases across all future time
I don't think it is possible for anyone to definitively say "having two
codecs brings no benefits to any use case".

4.    Browsers MUST support both H.264 and VP8, other entities MUST support
> at least one of H.264 and VP8
> .      Are you in favor of this option [Yes/No/Acceptable]:
>
> *NO*a.    Do you have any objections to this option, if so please
> summarize them:
> *Same as 2 and 3.*

Surely making browsers support both *does* meet the use cases where
compatibility with existing devices and servers is required.  As others
have already pointed out this means that general purpose programmable
end-points (browsers) will be compatible with new and legacy devices and
services, while dedicated native apps (that will inevitably be tied to
specific devices/services anyway) can be implemented to support just the
codec(s) needed.


Regards,


Peter