[whatwg] The issue of interoperability of the <video> element

[Jerason Banes]

> I believe an aim of whatwg is a viable implementable standard that
> reflects the realities of the web while encouraging innovation. MPEG4
> is part of the web (a growing part too).
>


If I may, I'd like to echo Timeless's point here. I've been watching this
thread with great interest and believe I understand both sides of the issue.
Theora is appealing because it provides a Free as in no-cost to implement
and Free as in no-encumbrances solution. However, it also provides a
solution that nobody uses today. Perhaps even worse, there doesn't seem to
be a lot of interest in adopting Theora in the future.

And can you blame web users? Theora provides a solution that's high
bandwidth and low quality. A very unappealing prospect for the
bandwidth-constrained environment of the web.Thus more competitive solutions
like MPEG4, WMV, RealPlayer, and Quicktime have been dominating the web. The
most popular form of video streaming at the moment is actually the
H.263codec through Flash; a non-free codec which is running on a
platform that
can only roughly be considered a "standard".

If and when the Dirac
<http://en.wikipedia.org/wiki/Dirac_%2528codec%2529>codec is
completed, there will be a viable alternative to the non-free video
codec problem that might justify the risk/reward equation for support. Until
then, however, we're going to need to look at supporting the existing
infrastructure. That infrastructure is based on the following options:

   - VP6
   - Windows Media Video
   - MPEG4
   - RealVideo 30/40
   - H.263
   - Quicktime Sorenson

Out of those solutions, VP6, WMV, Sorenson, and RealVideo can immediately be
discarded for their lack of standardization. That leaves H.263 and MPEG4 as
the only viable options.

H.263 is not a bad choice, IMHO. It's well supported by nearly every major
video player, has a variety of library implementations available, is in
widespread usage, and has a good tradeoff between bandwidth and quality. It
is also a standard under the ITU-T.

But what about MPEG4? Specifying MPEG4 has a lot of appeal for both its
excellent encoding performance and its single point to obtain licensing and
indemnity from. Furthermore, MPEG4 has its own container format and
low-bandwidth audio encoding scheme. (AAC is a sight better than having to
dictate ADPMC sound.) MPEG4 is also widely supported by media players,
though not quite as well as H.263. The MPEG Group also offers low-cost (i.e.
"free") licensing to anyone shipping less than 50,000 units a year, which
means that it would be feasible for upstart browsers to support the
standard.

That being said, I think I prefer the H.263 standard as a video baseline for
a few reasons:

   1. It presents several licensing options. The implementer can chose to
   get indemnity via an available license like MPEG4-Simple (which will play
   H.263), choose to try and deal with individual patent holders, or
   simply attempt to ignore the issue. (The last case is particularly appealing
   in countries that don't recognize the patents related to streaming video
   technologies.)
   2. It's amazingly well supported both in hardware and software. Future
   mobile devices should have no trouble adding support for H.263.
   3. It's already the most popular codec on the web today. While Real
   has "retired" their H.263-based codecs, it still lives on in Adobe FLV
   files.
   4. Java decoders are available for creating "shunts" for browsers that
   don't currently support the "<video>" tag.

That leaves me with two (point 5) questions:

   1. Would this place too much of a burden on browsers like Mozilla and
   Opera? Could plugins to local OS codecs or media players slide around the
   licensing issues?
   2. Is there a good choice for container format that wouldn't
   additionally burden the implementors?

Thanks,
Jerason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070626/dc86dbf0/attachment-0001.htm>