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

[Jerason Banes]

Hi Charles,

While I agree with your sentiment, I don't see a better option. The purpose
of the HTML5 spec is to provide a unified web applications platform that
supports the existing web in a practical manner. If the spec sticks with
Theora as the baseline implementation, it runs the risk of no one
implementing that part of the specification. If no one implements the Theora
codec, then the attempts to standardize the <video> tag will be all for
naught.

At the end of the day, I think the decision will come down to one of two
options:

   - The spec can specify Theora as the baseline, very few browsers will
   implement it, few users will use it (due to a lack of support), and thus the
   intent of standardizing on a free format will be lost.
   - The spec can be practical about implementing the <video> tag and
   specify H.263 or MPEG4 as a baseline. Existing multimedia toolkits can
   be reused in implementation and thus all browsers can support the standard.
   Users will use the format thanks to ubiquitous support. The "tax" will be a
   non-issue in most cases despite leaving a bad taste in the standard
   committee's mouth. Up and coming browsers can choose not to implement that
   part of the standard if they so choose or piggyback on an existing media
   player's licensing.

I personally think that having a non-free standard implemented in all
browsers is preferable to having a free standard implemented in none.
Otherwise, what is this tag being standarded for? We already have a mishmash
of options available through the "embed" and "object" tags.

It also occurs to me that the market is likely to define a format like MPEG4
as the "standard" whether the WHATWG wants it to or not. If the
least-common-denominator across browsers is MPEG4 (for example), then why
would the market embrace spotty support for theora? The practical solution
will win out regardless of what is decided here. Which will force new
browsers to support a pseudo-standard rather than a real standard, anyway.
Exactly the type of thing that the WHATWG was formed to prevent.

Thanks,
Jerason

On 6/26/07, Charles Iliya Krempeaux <supercanadian at gmail.com> wrote:
>
> Hello Jerason,
>
> From a technical point-of-view, you make a very good argument.
>
> However, I think it is inappropriate for the HTML spec to (directly or
> indirectly) mandate people pay to implement it.
>
> As you point out, H.263 is encumbered by patents and has licensing
> costs associates with it. Costs that me, you, tool creators, and users
> will have to pay, either directly or in-directly
>
> This just makes things more expensive for everyone since we are
> essentially being "taxed". And it's ridiculous to just accept this tax
> when there's no reason we have to.
>
>
> See ya
>
> --
>     Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/>
>
>
>                   All the Vlogging News on One Page
>                          http://vlograzor.com/
>
>
> On 6/26/07, Jerason Banes <jbanes at gmail.com> wrote:
> >
> >
> > > 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.263
> > codec 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 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 SorensonOut 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:
> >
> > 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.)
> > It's amazingly well supported both in hardware and software. Future
> mobile
> > devices should have no trouble adding support for H.263.
> > 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.
> > 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:
> >
> > 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?
> > 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/12e74be0/attachment-0001.htm>