Feed Sign in with OpenID OpenID

Simon Willison’s Weblog

HTML5 Media Support in WebKit. WebKit continues to lead the pack when it comes to trying out new HTML5 proposals. The new audio and video elements make embedding media easy, and provide a neat listener API for hooking in to “playback ended” events.

Tagged , , , , , , , ,

9 comments

  1. Doesn't actually solve the problem, though, because it'll only play video that you already have codecs for. So OS X will play QuickTime out of the box, Windows will play WMV out of the box, Linux will play Theora out of the box, and John Q. WebDev *still* doesn't have a way of actually embedding a video in any useful way.

    sil - 13th November 2007 01:41 - #

  2. sil: the HTML5 spec states that "[u]ser agents should support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format."

    Both Gecko (Firefox etc.) and Opera have experimental builds with Ogg support. It's not very clear to me whether these WebKit builds do or if they only know the formats that QuickTime can handle...

    Raf - 13th November 2007 08:44 - #

  3. yeah, it doesn't "lead the pack"

    arty - 13th November 2007 10:32 - #

  4. Raf: I agree that the spec says that. Apple have been pretty clear on the WHAT-WG mailing lists that they're not going to support Ogg formats, apparently because they don't consider them to be free of submarine patent risk. There's a reasonable argument to be made that actually they're trying to bolster support for their own media formats at the expense of everyone else, but whether they're doing that is a decision that everyone needs to make for themselves.

    sil - 13th November 2007 12:12 - #

  5. @arty, nice argument.

    @sil, it doesn't solve the cross-platform compatibility problem, but that doesn't mean that's the only problem that needed solving.

    huxley - 13th November 2007 17:46 - #

  6. huxley: which other problems are there that need solving? At the moment, publishing video is a cross-platform nightmare, unless you decide to use flash video for everything. Now that everyone supports the <video> element in different flavours, publishing video is a cross-platform nightmare, unless you decide to use flash video for everything. What problems has this new initiative solved?

    sil - 13th November 2007 20:54 - #

  7. for one thing, what matters to ME as part of an HTML standard: providing a standard predictable way of coding for video in HTML.

    Specifying the Ogg format (assuming both Apple and Microsoft end up support it and Mozilla and Opera follow through) might solve YOUR crossplatform issue, but it doesn't solve the nightmare unless you are assuming everyone will convert every video in the past and only encode in Ogg in the future ... so what problems does Ogg solve (assuming both Apple and Microsoft end up support it and Mozilla and Opera follow through)? Not much unless you're willing to ignore any past and future non-Ogg video format.

    I'd love for it to be easier but expecting the HTML5 standard will solve the publishing video nightmare may not be realistic. I am happy for it to do what is in the mandate of the working groups.

    IANAL so I don't know if Apple's concern is valid or not, but I agree it isn't their primary one. The word SHOULD in standard speak doesn't require that a reason be the primary motivation only that it be reasonable. To my ignorant eyes and in today's patent crazy times, it doesn't seem unreasonable.

    huxley - 13th November 2007 22:44 - #

  8. okay, I overstate the case when I say "everyone will convert every video in the past and only encode in Ogg in the future" but one has to consider that not everyone will encode into Ogg whatever its merits.

    huxley - 13th November 2007 22:47 - #

  9. Huxley: I don't particularly care that the chosen format is Ogg Theora -- that's what the HTML5 spec mandates, so that's what I support. Realistically, the spec can't mandate a proprietary video format, since then you'd have an HTML5 spec that was impossible for some people to implement, which is rather contrary to the goal of a spec.

    The point is that people are referring to <video> as though it makes publishing videos as easy as <img> made publishing images, and <img> was easy precisely because all browsers supported specific image formats -- GIF, JPEG, and later PNG. Currently, with the video I have published, the hard part has not been "creating a plugin element", it's been "encoding the video into half a dozen different formats so that everyone can watch it", with the commensurate time required to encode and disc space needed to hold those formats. <video> does not even remotely solve that problem; writing a <video> tag is not seriously easier than an <object> tag for a video plugin.

    Take, for example, http://lugradio.org/listenalone which is a video that I published. I put it into four formats: MPEG-2 (broadly supported across platforms; patent-encumbered), MP4 (Macs, iPods, PSPs; patent-encumbered), Ogg Theora (no patents; natively supported on Linux, available on other platforms through plugins), and Flash video (via YouTube), as well as publishing to blip.tv to enable people with Java to watch the Theora format without having Theora installed. I had to publish all those formats precisely because there is no one cross-platform out-of-the-box format available. Now, there's a small amout of clever JavaScript which tries to work out which formats your machine supports and therefore display you that one, and I freely admit that being able to have one <video> element with a number of <source>s in it would make that aspect of the publishing easier, but surely to goodness the major problem that needs solving is not that "the HTML is a bit hard" but "video on the internet is a right pain that involves publishers creating four versions of identical content, and users understanding words like 'codec' when they shouldn't have to"?

    sil - 14th November 2007 10:06 - #

Sign in with OpenID

Auto-HTML: Line breaks are preserved; URLs will be converted in to links.

Manual XHTML: Enter your own, valid XHTML. Allowed tags are a, p, blockquote, ul, ol, li, dl, dt, dd, em, strong, dfn, code, q, samp, kbd, var, cite, abbr, acronym, sub, sup, br, pre

A django site