Re: [rtcweb] Straw Poll on Video Codec Alternatives

[Hervé W. <[e-mail]>]

>  1. All entities MUST support H.264
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

No

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Fixating on either H.264 or VP8 was not productive and don't like the
patent licensing situation. OpenH264 is generous, but far from perfect.

>  2. All entities MUST support VP8
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

No

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Fixating on either H.264 or VP8 was not productive and choosing VP8
while the Nokia claims are unresolved is not a good plan.

>  3. All entities MUST support both H.264 and VP8
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

No

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Twice the risk, twice the maintenance burden.

>  4. Browsers MUST support both H.264 and VP8, other entities MUST
>     support at least one of H.264 and VP8
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

No

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Twice the risk, twice the maintenance burden. Risk of negotiating
failure if multiple parties aren't browsers.

>  5. All entities MUST support at least one of H.264 and VP8
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

No

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Risk of negotiating failure.

>  6. All entities MUST support H.261
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

Yes

Quality/bitrate not as bad as MJPEG. Available bitrates go up, even in
mobile space.
Those 256kbit/s streams are just 31.25 kibibytes per second (32 kilobyte/sec).
Implementations aren't widespread now, but were.
vic, ffmpeg/libav, IVS, microsoft (M261), intel has at least one if
not more (intel's ipp library 7.0), pvrg-p64

>      b.     Do you have any objections to this option, if so please
>         summarize them:
>
>  7. There is no MTI video codec
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

No

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Risk of negotiating failure. Winding up with this situation is one
thing. Choosing it is quite another.

>  8. All entities MUST support H.261 and all entities MUST support at
>     least one of H.264 and VP8
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

No

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Twice the maintenance burden. Licensing burden for h264, unresolved
claims for vp8.

>  9. All entities MUST support Theora
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

Yes

IPR FUD was spread in the past without any followup claims despite
commercial products. http://wiki.xiph.org/Games_that_use_Theora
That's no guarantee, but neither is h264.
Uncertainty about its quality/bitrate is not a strong argument; tools
are freely available to encode and decode.

>      b.     Do you have any objections to this option, if so please
>         summarize them:
>
> 10. All entities MUST implement at least two of {VP8, H.264, H.261}
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Twice the maintenance burden. Licensing burden for h264, unresolved
claims for vp8. H.261 can be avoid by those that can and wish to do so.

> 11. All entities MUST implement at least two of {VP8, H.264, H.263}
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

No

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Twice the maintenance burden. Licensing burden for h264, licensing
burden for h263, unresolved
claims for vp8.

> 12. All entities MUST support decoding using both H.264 and VP8, and
>     MUST support encoding using at least one of H.264 or VP8
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

No

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Licensing burden for h264.

> 13. All entities MUST support H.263
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

No

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Licensing burden for h263

> 14. All entities MUST implement at least two of {VP8, H.264, Theora}
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Twice the maintenance burden. Licensing burden for h264, unresolved
claims for vp8.

> 15. All entities MUST support decoding using Theora.
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

No

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Could still cause negotiation failure if the implementer just wants a
rubber stamp that says 'rtcweb compliant' and does not implement
Theora encoding.

> 16. All entities MUST support Motion JPEG
>
>      a.     Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

>      b.     Do you have any objections to this option, if so please
>         summarize them:

Worse performance than h261.


- Hervé