Helping video understanding

Apple-oriented pundit John Gruber writes of his understanding of showing video in browsers. Here are some tidbits which may help:

  • HTML 4.0 did deprecate the realworld EMBED tag, but the Apple/Google/WhatWG “HTML5” proposals bless it again.
  • VIDEO tag is not a Standard, nor a W3C Recommendation… this shouldn’t stop your experimentation, but neither should the label “standard” stop you.
  • Congratulations on moving past the very proprietary “QuickTime”… the stewardship of that proposal has been disappointing.
  • If thinking of VIDEO tag, you must think of codecs too… Ogg Theora decoders and VIDEO tag parsing do not completely overlap.
  • It’s fortunate that this experimentation was performed on a site where two-thirds of the visitors use Apple-branded browsers. Most sites don’t enjoy the luxury of such near-monoculture.
  • Yes, buffering and startup behavior, like codecs, are issues which were not adequately addressed in the spec. Specifying a VIDEO tag was an easy first step, but does not suffice… captioning, for instance, has been a particularly divisive omission. The WHATWG proposals make more sense as a “blessing” of what Apple was going to do anyway.
  • “I think the HTML5 spec should be changed such that the value of the autobuffer attribute may not be ignored.” May be difficult, due to last call.
  • “Why would I publish content using a technology that I personally block by default?” Because it works.

Two incidental followups: I’m still seeking the factual basis of that surprising claim “We know for a fact that Adobe has no interest in the Mac implementation’s quality,” and if you could correct that prior “arrogance” claim to reflect what I actually said then that would be great, thanks.

[Comments: Ideas are good, but trolls won’t be fed.]

7 Responses to Helping video understanding

  1. Jared says:

    For at least the partial basis for Adobe not caring about Mac all you have to do is look at the release notes for Flash Player 10.1 where hardware video decoding of H264 is not supported.
    http://labs.adobe.com/technologies/flashplayer10/releasenotes.pdf
    “In Flash Player 10.1, H.264 hardware acceleration is not supported under Linux and Mac OS. Linux currently lacks a developed standard API that supports H.264 hardware video decoding, and Mac OS X does not expose access to the required APIs. We will continue to evaluate adding the feature to Linux and Mac OS in future releases.”
    [jd sez: Are you guessing that was the “fact” to which Gruber referred? It would seem a weak proof, because Adobe would be happy to use hardware acceleration, were Apple to permit it.]

  2. I’m pretty sure you’ll just call this a troll and not post it, but you’ll probably read it first.
    Of course we know that Adobe doesn’t care about Flash’s quality on the Mac. We have nearly a decade now of a horribly inferior product. This isn’t even up for discussion as far as any rational person is concerned. Not only has the jury returned, but the execution has already been carried out.
    And trolls like your post here aren’t helping at all.
    [jd sez: iow, facts don’t matter ‘coz you have your belief, got it. Thanks for the illustration of why it’s more productive to not publish the brand-obsessed. Back to video….]

  3. J. King says:

    I don’t see how the spec being at last call (which it isn’t yet, in any formal sense) has any bearing on whether a broken feature should be fixed. That’s what implementation experience is for, and both in the WHATWG and W3C processes call for implementations comes after last call (though last call is merely informal in the WHATWG process; the charter makes no mention of it).
    It’s unfortunate we have shipped implementations which are less than ideal, but it’s certainly not the first time such a thing happens, and if the current behaviour is decided to be too disruptive by content producers then I don’t see why it wouldn’t change: that’s who the implementors would want to serve in this particular case.

  4. Lewis Francis says:

    What astonishes me about Gruber’s post is his logic on Flash-blocking — what’s he going to do if and when advertisers start delivering their pitches via HTML 5 video?

  5. I think the codec issue is a big one. John’s speaking from the point of view from a guy who does 2 videos a year.
    We run a video hosting service, and the needs are very different from 2 videos a year on my own site.
    I can pretty firmly say the “encode into two formats for HTML5 video” is not going to take off. For loads of reasons, including simplicity and cost.
    As a video widget, flash just works. HTML5 does not, yet and it will be some time before it does. When it does we will perhaps serve it too, but till then, we have a business to run, and so need to go with something that “just works”

  6. Ben Ward says:

    @Lewis Francis: As I understand it, Gruber’s evangelism of ClickToFlash is nothing to do with blocking advertisments—he runs static ads from The Deck on his own site.
    He advocates blocking Flash as the Flash plugin on Mac OSX causes an unreasonably large increase in processor usage, causes cooling fans on MacBooks to go into noisy full-thrust when before they were near-silent, and being a major cause of crashing the entire Safari web browser (Apple’s claim, from the Snow Leopard keynote earlier this year.)
    [jd sez: Lewis raised the point that assuming “HTML5” will be more efficient is questionable, and that corresponding “VIDEO-blockers” were not yet considered. Apple’s utility identified Flash, but often these are plugin-to-browser memory requests which the host did not successfully fulfill…!]
    The result of running Safari with ClickToFlash is that web pages load faster, and Safari uses less resources. Gruber advocates it because it improves user experience to block Flash content.

  7. Ben Ward says:

    “assuming “HTML5” will be more efficient is questionable”
    There’s no need for assumption. ClickToFlash for Safari already enables rendering YouTube videos using the HTML5 `video` element. Users are able to observe that playing video using the browser’s native video implementation (which in Safari’s case, uses Quicktime under the hood) doesn’t slow their machine and doesn’t start up the fans. [jd sez: QuickTime uses privileged Apple APIs for video decompression. Adobe would use them if Apple permitted. Windows is more open. And a Mac constriction has no effect on my statement you quoted.] YouTube also produced an HTML5 + JavaScript version of their video player for demonstration purposes: http://youtube.com/html5
    When YouTube demo’d 1080p video, the Flash player choked a brand new, 2.5Ghz, 4GB RAM MacBook. The video stutters at a couple of frames per second, Activity Monitor reports 100% CPU usage throughout. The exact same video file played back using the `video` element? 20% CPU. Perfect smooth playback. Not a lab test, not hypothetical, actual observed results on a consumer machine. [jd sez: And you seem to assume this is due to something which works well on more open systems.]
    It’s not that HTML5 video “will be” more efficient than Flash. HTML5 video is more efficient, right now.
    If you mean that it’s not clear whether HTML5 will be more efficient than some hypothetical future version of Flash [jd sez: Nope.], that’s irrelevant and vapourous. People block Flash now because it improves their browsing experience today. If Flash gets fixed in the future then people may stop blocking it.
    As for add-ins designed to block the `video` tag (or, I think just as likely, browsers themselves allowing video/audio rendering to be manipulated through preferences), that’s just fine; HTML fails gracefully if external media is missing. Blockers probably will be written, if people find reasons for it. But based on the existing, stable implementation of `video` in Safari, people will not be choosing to block `video` due to performance and stability problems, because performance is showing to be excellent. Performance is the reason that people block Flash. [jd sez: If you’ve read me, you’ll know I’ve been personally using a Flash blocker for over five years, because you cannot trust people on the Web to not push stuff at that isn’t worth your time. Perhaps others feel the same….]