- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 31 Oct 2006 14:50:41 +0200
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