Re: [rtcweb] Straw Poll on Video Codec Alternatives

[Silvia Pfeiffer <[e-mail]>]

Here are my personal thoughts on the different options put in front of
us at this point in time.

1. All entities MUST support H.264
  .a No
  .b The licensing situation of H.264, where you have to pay a license
to MPEG-LA and to companies like AT&T (see
http://www.att.com/gen/sites/ipsales?pid=19116) is not acceptable:
* not for an open Web (imagine if we all had to pay license fees for
the use of UTF-8 or ASCII - how much limited would we be to publish
content/communicate - any bureaucracy is an obstacle to innovation and
non RF-licensing is such an obstacle),
* nor for the open source community (see
http://sgallagh.wordpress.com/2013/11/06/ietf-mti-codecs-and-fedora/
for a clear discussion of why OpenH264 is not a solution),
* nor does it agree with the IETF's preference of using technologies
with no known IPR claims, or with royalty-free licenses (see rfc3979),
* nor dies it agree with the W3C's assurance that Recommendations can
be implemented on a royalty-free (RF) basis (see
http://www.w3.org/Consortium/Patent-Policy-20040205/).
Therefore, having H.264 as the one and only MTI is not acceptable.


2. All entities MUST support VP8
  .a Acceptable (0.95)
  .b VP8 satisfies the IETF's preference of royalty-free licenses more
so than H.264, because it covers both encoders and decoders, while the
H.264 IP licenses are only for decoders and because all known patents
(bar one) are available royalty-free.
The agreement between Google and MPEG-LA is reassuring for the IPR of
those 11 companies that were part of the VP8 pool at MPEG-LA
(http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachments/88/n-13-03-07.pdf).
The VP8 cross-license agreement with further companies
(http://www.webm-ccl.org/vp8/primary-licensors/) is further
reassuring.

The Nokia IPR declaration (https://datatracker.ietf.org/ipr/2035/)
without willingness to license is obviously an issue for some of us.
As much as I have a gut feeling that the Nokia claims are only patent
trolling, there is certainly FUD.
I would go to 100% "Yes" if there was an analysis of the Nokia IPR
that credibly refutes the claims.


3. All entities MUST support both H.264 and VP8
  .a No
  .b Having both codecs supported helps bring interoperability with
legacy devices into WebRTC.
However, we cannot require the implementation of H.264 for the reasons
stated in 1.b.
Also, a clean cut is likely more appropriate and makes it easier to
move into a brave new world of video connectivity.


4. Browsers MUST support both H.264 and VP8, other entities MUST
support at least one of H.264 and VP8
  .a No
  .b Browsers are just sample players. If we accepted a rule like
this, we would need to extend it to all players, including mobile
phone apps, desktop apps etc.
Such a rule would clearly split the WebRTC world in two camps, with
browsers being the link between them, which is not desirable.


5. All entities MUST support at least one of H.264 and VP8
  .a No
  .b This is just as bad as not choosing an MTI codec, see 7.b.
It also splits the world into two camps, which can only interoperate
with live transcoding services, which introduces latency and is
therefore not desirable.


6. All entities MUST support H.261
  .a Acceptable (0.40)
  .b It's as bad as going back to G.711 for audio. But since it would
only be used where devices do not speak the same higher quality codec,
it might be acceptable. This might be more future-proof than the
{H.261, H.264, VP8} combination, since H.265, VP9 and even Daala are
already on the horizon.


7. There is no MTI video codec
  .a No
  .b We might as well give up on standardisation efforts, since this
does not provide for any interoperability.
Having said this, I believe if we drag out the MTI selection a bit
longer, we may end up with better choices, such as VP9 or Daala for
which the patent situation should be cleaner.


8. All entities MUST support H.261 and all entities MUST support at
least one of H.264 and VP8
  .a Acceptable (0.40)
  .b I think we can achieve the same effect with 6. but 6. is a bit
more future-proof
Also, requiring the support of several codecs certainly increases
maintenance requirements, but a compromise is certainly required.
Maybe H.261 as the MTI and a recommendation on H.264 or VP8 as the
newer codecs to implement right now with a need to revisit every 2
years or so.


9. All entities MUST support Theora
  .a Acceptable (0.45)
  .b Theora is an older codec than VP8 - I thought the world had moved
on to VP8 by now, both from a quality and from an IPR POV.
However, if we have to pick an old codec, I would prefer Theora over
H.261 as the MTI for its better quality/bandwidth use.


10. All entities MUST implement at least two of {VP8, H.264, H.261}
   .a Acceptable (0.35)
   .b It's effectively the same as 8 and thus 8.b applies.


11. All entities MUST implement at least two of {VP8, H.264, H.263}
  .a No
  .b H.263 is as much encumbered as H.264, so why go back to an older
codec that has the same IPR issues. All issues of 1.b still apply to
this option.


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 Acceptable (0.05)
  .b Same as 3.b except not every device has to do both codecs, which
is easier for creating applications that only serve part of the
market.


13. All entities MUST support H.263
  .a No
  .b same as 11.b


14. All entities MUST implement at least two of {VP8, H.264, Theora}
  .a Acceptable (0.40)
  .b Same as 9.b and 6.b. Theora has less licensing issues than H.263
and is newer than H.261.


15. All entities MUST support decoding using Theora.
  .a No
  .b This is not a solution to MTI - a video conference needs both
decoding and encoding ends to interoperate.


16. All entities MUST support Motion JPEG
  .a Yes, but not as the only MTI
  .b I actually like adding Motion JPEG as a codec, because JPEG
decoding is readily available. However, M-JPEG is not a solution for
the video MTI codec because of it's high bandwidth need and poor
adaptability to available bandwidth. I'd want it, however, as a
solution to low framerate, high resolution video needs such as
document cameras and maybe even screen sharing. This should be a
separate discussion.


Some summary thoughts:

If it wasn't for royalty-free codecs such as Theora, VP8, VP9 and
Daala, we would be completely at the mercy of the MPEG-LA and the
other patent holders of H.264 for video-based Web technology. The
MPEG-LA monopoly thus far had quite a hold on the corporate video
market. Only the recent introduction of better licensing terms allowed
the introduction of new players into this market and created new
competition and cloud-based solutions. WebRTC should further improve
on this situation and not close down the market again by reinforcing
the monopoly. The only sensible solution is to have a royalty-free MTI
codec - a RAND codec can be an optional addition only.


Regards and hope you all had a Merry Christmas,
Silvia.