W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2006

[whatwg] Video

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 31 Oct 2006 14:50:41 +0200
Message-ID: <5EAE3E3E-26B7-4D5E-BA6A-C8D88A715CDC@iki.fi>
On Oct 31, 2006, at 07:43, Lachlan Hunt wrote:

> Perhaps, to go along with the Audio() interface, we could have a  
> Video() interface as well.  Maybe it would be wise to introduce a  
> MultiMedia() interface, which is then inherited by both the Audio()  
> and Video() interfaces and extended by each with APIs specifically  
> for their respective media.  e.g. Video() could have an API for  
> capturing a frame and exporting it as a JPG or PNG.

> Defining which video format for browsers to support is out of scope  
> of the WHATWG and HTML5.  However, I do agree that there needs to  
> be a more widely supported format so that websites don't have to  
> offer the user a choice (commonly WMV, Quick Time and Real).  If  
> offered a choice, it should only be to pick one suitable for their  
> bandwidth.

These are not technical problems but legal ones. Browser vendors are  
wise to stay at an arms length from video formats due to patents.  
There's a suite of standards for this stuff: MPEG-4. This isn't about  
lack of de jure specs or technology. If there weren't patents on  
MPEG-4, browser vendors could integrate support for H.264 video with  
LC-AAC audio in an MP4 container and the problem would be solved-- 
just like browsers include support for JPEG. However, JPEG and MPEG-4  
are substantially different from the legal perspective.

What browser vendors could do is move the point of plugging  
encumbered modules to a different place. That is, browsers could hook  
up to Gstreamer, QuickTime or the Windows Media framework and leave  
codecs and stream splitters to be plugged on the generic video  
framework level. But this would mean inheriting the limitations of  
the video framework in terms of what can be plugged. And on Windows  
the framework gatekeeper is hostile and on Mac OS X the framework may  
have technically unsatisfactory limitations.

(I am not sure if the Windows Media framework is flexible enough to  
allow MP4 and Ogg stream splitters and corresponding streaming  
protocol clients to be plugged.)

> It would be very nice to have a widely supported, non-proprietary,  
> patent free format on the web, which is also completely free of DRM.

Agreed.

> I would love to see Ogg Vorbis/Theora become as successful in the  
> audio and video market as PNG has for images, but the current  
> problem holding it back is the lack of implementation in the major  
> media players and browsers.
...
> Aside from the companies who have a stake in proprietary formats,  
> I'm sure they would like to because they could save money on  
> licensing fees.

It isn't just the network effects of installed base (lack thereof)  
that are holding Theora back. Theora is not technically as advanced  
as H.264 or WMV9 (or even H.263 apparently). In general, a Theora- 
encoded video requires more CPU power for decompression than a  
comparable video encoded using a codec encumbered by the MPEG-LA  
portfolio. Also, to achieve similar subjective quality, you need more  
bits with Theora than with recent codecs encumbered by the MPEG-LA  
portfolio. According to Chris DiBona, the bandwidth issue is why  
Theora is not good enough for Google Video. Also, he said that Google  
does pay MPEG-LA, so I guess Google has figured that paying MPEG-LA  
costs less than the additional bandwidth required by Theora (plus the  
installed base issues).

And about stakeholders: If you look at who have stuff in the MPEG-LA  
and Via Licensing portfolios and who ship handheld devices, it  
becomes apparent that not only does it seem that key handheld vendors  
have their protection sorted out but they also have an interest in  
the portfolios.

P.S. Those who read Finnish may be interested in
http://www.effi.org/sananvapaus/videotiedostomuoto.html

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
Received on Tuesday, 31 October 2006 04:50:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:29 UTC