Re: [rtcweb] Straw Poll on Video Codec Alternatives

[Basil Mohamed Gohar <[e-mail]>]

On 12/09/2013 12:24 PM, Ted Hardie wrote:

>  1.
> 
>     All entities MUST support H.264
> 
>      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:

H.264 carries with it an explicit licensing burden that will bring with
it exclusion of use cases, including but no limited to free software
implementations (as defined by the Free Software Foundation) and stifle
adoption of the standard as a result.  This will effectively limit
rtcweb to "the same old players" that are already entrenched in the
market and lock out smaller entities.

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

YES

> 
>      2.
> 
>         Do you have any objections to this option, if so please
>         summarize them:
> 
>  3.
> 
>     All entities MUST support both H.264 and VP8
> 
>      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 same objections in #1 apply here.  Additionally, it should be noted
that the parallel of "two MTI audio codecs" cannot apply here because
there were no free software licensing issues in the two proposed codecs
that would impede adoption.  This is not the case with H.264, to be precise.

> 
>  4.
> 
>     Browsers MUST support both H.264 and VP8, other entities MUST
>     support at least one of H.264 and VP8
> 
>      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:

In addition to the challenges presented by mandating H.264 as mentioned
above in my objections in #1 and #3 above, this one has the additional
challenge of applying different rules on an arbitrary and ambiguous
distinction.  What, exactly, is a browser?  Can the same application be
a "browser" sometimes, and a "phone" another time?  Having this in the
spec would likely be a great hindrance to adoption, even if the
currently known interested browser vendors agree, it would not be
representative of any future additional ones.

As a point to note, until relatively recently, Chrome as a browser did
not exist, and before that Safari did not, and before that Firefox did
not, and before that Opera did not, and before that Internet Explorer
did not.

> 
>  5.
> 
>     All entities MUST support at least one of H.264 and VP8
> 
>      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:

While this option gives a wider choice of what codec to implement, the
result will be two "islands" in the rtcweb world - the H.264 one and the
VP8 one.  This alone will not yield any mechanism with which to
guarantee interop between rtcweb clients.

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

YES

> 
>      2.
> 
>         Do you have any objections to this option, if so please
>         summarize them:
> 
>  7.
> 
>     There is no MTI video codec
> 
>      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:

This will result in the same problem as presented in 5, namely, islands
in the rtcweb world.  Therefore, it's not a good option.  Comparisons to
HTML5 <video> are apt, in that, despite being years old and supported,
no single standard codec emerged as suitable for all cases by market
choices, and we still have some sites only supporting certain codecs
(e.g., Vimeo) and even some switching the nature of what they support
(e.g., YouTube) isolating certain user agents and therefore users.

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

YES

> 
>      2.
> 
>         Do you have any objections to this option, if so please
>         summarize them:
> 
>  9.
> 
>     All entities MUST support Theora
> 
>      1.
> 
>         Are you in favor of this option [Yes/No/Acceptable]:

YES

> 
>      2.
> 
>         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}
> 
>      1.
> 
>         Are you in favor of this option [Yes/No/Acceptable]:

YES

> 
>      2.
> 
>         Do you have any objections to this option, if so please
>         summarize them:
> 
> 11.
> 
>     All entities MUST implement at least two of {VP8, H.264, H.263}
> 
>      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:

This option, while seemingly offering a wider choice, will force a valid
implementation of rtcweb to include royalty-bearing code for either
H.264 or H.263, neither of which can currently be implemented nor
deployed without exposing the implementor or the user to some licensing
fees.

> 
> 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
> 
>      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:

Only decoding H.264 video does not fully eliminate the licensing issues
that were mentioned in my previous points, therefore it is not any
better than them.

> 
> 13.
> 
>     All entities MUST support H.263
> 
>      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:

H.263 is not any better off than H.264 from a licensing perspective, and
may actually be worse in that manner.

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

YES

> 
>      2.
> 
>         Do you have any objections to this option, if so please
>         summarize them:
> 
> 15.
> 
>     All entities MUST support decoding using Theora.
> 
>      1.
> 
>         Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

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

This sounds like a weak option because it doesn't imply much about the
rest of the implementation.  It does, however, imply that at least one
side of each rtcweb communication setup support encoding with Theora,
which is something I am already for.

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

Acceptable

> 
>      2.
> 
>         Do you have any objections to this option, if so please
>         summarize them:
> 
> 
> 
> H.264 is a reference to the proposal in
> https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/
> 
> 
> VP8 is a reference to the proposal in
> https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/
> 
> 
> Theora is a reference to Xiph.org Theora Specification from March 16,
> 2011 (http://www.xiph.org/theora/doc/Theora_I_spec.pdf)
> 
> 
> H.263 is a reference to profile 0 level 70 defined in annex X of ITU-T
> rec H.263 (http://www.itu.int/rec/T-REC-H.263/)
> 
> 
> H.261 is a reference to http://tools.ietf.org/html/rfc4587
> 
> 
> Motion JPEG is a reference to http://tools.ietf.org/html/rfc2435
> 
> 
> 
> Thanks,
> 
> 
> The Chairs

-- 
Libre Video
http://librevideo.org