Re: [rtcweb] Video codec selection - way forward

[Maik Merten <[e-mail]>]

Dear Ross,

thanks for providing your thoughts on this proposal. Your analysis quite 
perfectly reflects my reasoning.

I think there is consensus that both H.264 Constrained Baseline and VP8 
are capable of delivering high quality video. However...

  - the camp opposing VP8 fears that Google is not in complete control 
of the surrounding IPR situation
  - the camp opposing H.264 presented diverse examples where H.264's 
licensing is not compatible with their very operating principles

I currently do not see how this can be resolved in such a way that each 
camp is happy.

There apparently is consensus, however, that negotiation failure should 
be avoided and that high video quality is desirable, meaning that 
entities are very welcome to implement both high performance codecs. 
This does not appear to be possible for all participants, so to avoid 
negotiation failure while working around IPR issues something like H.261 
looks quite promising IMO. While some participants rightfully question 
the place such an antique codec may have in our HD world, I'm still 
fully convinced that transmitting CIF video can still be very much 
desirable over forcefully transmitting no video at all: that resolution 
still transports emotions, facial features and sign language (which is 
relevant to those concerned with accessibility).

It can also be demonstrated that objective quality measures such as PSNR 
and SSIM favor transmission of low resolution video over a static black 
picture ;)

Again in a nutshell:

  - nobody is forced to implement a codec they object to on IPR grounds
  - we never have negotiation failure and can always transmit video 
(albeit not always beautiful video)
  - implementations that are always able to transmit high quality video 
do not need to be concerned with implementing a low quality video codec


Best regards,

Maik


Am 18.11.2013 07:58, schrieb Ross Finlayson:
>> just wondering if something like
>>
>> "9. All entities SHOULD support both H.264 and VP8. All entities MUST
>> at least implement one of those. Entities that do not support both
>> H.264 and VP8 MUST implement H.261."
>>
>> has already popped up. My reasoning is that implementations supporting
>> both high performance codecs will always negotiate to use on of those
>> - H.261 should never be relevant there.
>
> This looks promising.  To summarize: You're proposing that each
> implementation MUST implement (at least) one of the following sets of
> codecs:
> {VP8, H.264}
> {VP8, H.261}
> {H.264, H.261}
>
> This guarantees that there'll never be negotiation failure (between a
> pair of implementations), because the intersection of any two of these
> sets is non-empty.
>
> It also allows the H.264 camp to avoid any alleged additional IPR risk
> from implementing VP8, because they won't need to implement VP8 (they'll
> need to implement H.261 instead).
>
> Similarly, it also allows the VP8 camp to avoid any H.264 licensing
> requirements, because they won't need to implement H.264 (they'll need
> to implement H.261 instead).
>
> And people who are willing to implement both VP8 and H.264 will know
> that they'll always be able to negotiate high-quality video.
>
> Who knows - this may well be something that we could reach consensus on
> (provided that everyone agrees that there's little IPR risk from H.261)...
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>