VIDEO debate, cutting to the chase

Earlier this week Google’s Chrome team announced that they’d no longer be including an H.264 video decoder in their browser. I haven’t seen any updates from them responding to the massive third-party conversation following their use of the fluffy and prone-to-dispute “because it’s open” explanation.

But that massive conversation seems to hide more than it reveals — burying us all under word fatigue. Here are some simple basics:

  • The VIDEO tag was simply not well-considered at the outset. Its original rationale was: “You don’t require a plug-in to view images… video is the next natural evolution of that.” But from the very start the practical questions about use were swept under the rug… at least until the rug started piling up too high. It wasn’t sustainable.
  • The VIDEO tag serves two different constituencies: those with an “Open Web” banner who wanted to expand their own scope (lookin’ at ya, Mozilla), and those who have invested in Apple and their devices. These two groups have had different needs. The original proponents from Mozilla and Opera saw their desires for a royalty-free codec (for royalty-free tooling) hijacked by Apple fans’ needs for an H.264-baseline implementation. It wasn’t sustainable.
  • Video publishers need the VIDEO tag for one purpose only: to support Apple’s non-standard HTML browser and its denial of third-party extensibility via APPLET, OBJECT, and EMBED. [I’m copying that linked comment below, because TechCrunch’s Disqus commenting system doesn’t seem very web-friendly.] Flash’s popularization of H.264 meant that much video did not need to be re-worked for Apple’s standard-breaking devices, just the tagging and — significantly — the interactive and adjunctive features of anything beyond plain linear video playback. This may have been endurable, but the demand from the start was not sustainable.
  • Does Chrome’s H.264 move affect Chrome users? I don’t know of any (non-ideological, non-Apple-only) video which uses only VIDEO/H.264. The only real effect it seems to have is to blunt Apple’s campaigning by removing a nominal incentive. iPad users may be most affected, but impact on Chrome users seems minimal. Its removal does not seem unsustainable.
  • In this week when we’ve seen Arizona shootings and the easy (and incorrect) apportionment of blame, it’s quite unsettling to see how techblogs go on about the “war” and “blood feud” and other speech which is meant to incite, and earn more ad revenue. For goshsakes, consider how you’re speaking. Reflexive hatred is not sustainable.

Beyond the pettifoggery of This Week’s Blog Outrage, a simple truth remains: We humans are now witnessing a migration of video interactivity to pocket device. People all around the world, from varied economic strata, can now capture what they see and share it with others. It’s right up there with the invention of printing and the invention of the Internet. Instead of arguing about branding issues we should be thinking of how people will want to use video, how they will need to use video. This would be more sustainable. Would be more useful, and kinder, too.

16 Responses to VIDEO debate, cutting to the chase

  1. John Dowdell says:

    Addendum: I’m copying a comment at TechCrunch here, because the linking system requires button-pressing and scanning to view. (Sometimes I wonder whether techblogs include so many garbage comments simply to dissuade people from reading other viewpoints.) The comment is from someone identified only as “NotBoss”. I’m ambivalent about people who won’t “own their words”, but while anonymity is useless for “here’s what I think” declarations, anonymity is neutral when presenting observations & hypotheses which had not yet been entered into the debate. Whoever this writer is, s/he presents the issue of Apple’s rejection of W3C standards very well.

    I think you’ve missed an important point about Google and Flash. Google has an obligation to follow open Web standards in Chrome. HTML 4 and 5 both include support for plugins. If you don’t believe me please skim this section of the most recent HTML5 draft:

    Note that support of plugins are explicitly required by the HTML5 proposal. For example:

    “The object element can represent an external … resource to be processed by a plugin.”

    And also:

    “If the resource type is not a type that the user agent supports, but it is a type that a plugin supports… the user agent should use the plugin that supports resource type and pass the content of the resource to that plugin.”

    These requirements are not optional. To support HTML5 (or HTML 4) browsers must implement plugins.

    So Google must support plugins, including Flash, in Chrome. The problem for Google and others is HOW to support plugins.

    Google and Adobe are in a partnership that involves making plugins work better on mobile devices and in laptops/desktops. In the mobile space the focus is on performance and battery life. But, across all devices there is also a need for better security – including managing plugin cookies, process isolation, and better sandboxing.

    Bundling Flash into Chrome is likely part of how Adobe and Google agreed to work together on those problems.

    While you may debate how browsers manage plugins there is no debate that plugins are part of the Web. They are required by the HTML standard of today and the proposals for tomorrow. Google’s work with Adobe will provide safer ways to manage plugins. You can hate Flash all you want, but you should also try to understand what the HTML standard requires and how Google’s work with Adobe is making the Web a safer place.

    Frankly, I think the hypocrisy you smell doesn’t exist. H.264 is not part of any Web standard or proposal and it was never going to be supported by Mozilla and Firefox. Google is investing considerable resources in trying to provide the Web with a free and unencumbered codec. If they succeed it will, over the long term, make producing video content on the Web easier.

    Finally, while Apple and Google have competing interests there is more to the video and Flash stories than Apple vs. Google, Apple vs Adobe, or Apple vs Microsoft.

  2. Darryl H. Thomas says:

    “These requirements are not optional. To support HTML5 (or HTML 4) browsers must implement plugins.”

    This is a significant misinterpretation of the spec, leading to a false conclusion. Browsers must implement support for the elements defined in the spec and traverse the chain of content handlers. If a given plugin is not available (or a given content type cannot be otherwise handled by the browser), the spec defines a fallback mechanism:

    The statement that “Google must support plugins, including Flash” is not accurate. The browser must support the “object” element, but nowhere in the spec is it stated, or implied even, that Flash must be supported; only that if it is NOT supported, it must be able to fallback gracefully. I’m not saying that Google shouldn’t include Flash support, but the assertion that Apple is violating standards by not including support for Flash is patently false.

    • notboss says:

      Hi Darryl,

      The object tag isn’t just a tag that must be parsed. The HTML proposals make it clear that there must be a mechanism in the browser to support handing off content to a plugin. If a browser vendor does not provide that mechanism then the browser is not fully compliant.

      The HTML proposals do not say HOW a browser implements plugins. But, it does describe what the end result is: content is handed from the browser to the plugin. The fall back you mention is for when a plugin has not been installed in the browser – not when a plugin mechanism is not available in the browser. I think the documents are clear on that. When a user gets the fall back message the user can decide to install the plugin or not. For the user to make that decision the browser vendor must support plugins!

      Apple’s mobile browser takes that capability away from the user and does not provide a mechanism that supports plugins as defined in the HTML 4 standard and HTML5 proposal. So parsing a tag is not enough. The browser must act on the tag as required.

      Of course the HTML proposals don’t mention Flash by name. But I also think the HTML proposals clearly describe a general purpose extension mechanism for the Web (plugins) and that any browser provider is violating the standard if they try to claim that they don’t have to support the most used plugin on the Web.

      Of course its a moot point as Apple’s mobile devices do not support the general purpose extension mechanism (plugins) defined in the HTML 4 standard and HTML5 proposal.

      I think Google is to be commended for doing the difficult collaborative work with Adobe to make Flash run more safely within Chrome. I hope that work leads to better APIs that let us run all plugins – when we choose to – safely and efficiently within browsers.

      I could drone on about the history of the applet, embed, and object tags. But either you read the HTML standards and proposals in order to understand what a browser should do or you don’t. I think it’s pretty clear what browsers are supposed to do when it comes to plugins. Of course maybe I’ve got all this wrong. Can you show me please where it says browsers don’t really have to support plugins? Maybe there’s a preamble to the object tag that says doing more than parsing it is optional?

      • Darryl H. Thomas says:

        Hi again,

        When I read your response, I was about to apologize for oversimplifying things with the use of the word “parse,” but upon re-reading what I had written, I noticed that I hadn’t used that word. I said “implement support for the elements defined” and linked to the prescribed/mandated fallback mechanism. I neither said, nor in my view implied, that simple parsing of the tag was sufficient. If you believe that’s what I was implying, I apologize for the confusion.

        From my reading of the spec, and it’s possible I’ve missed something, there’s no strict requirement that a browser/user-agent provide a plugin architecture, much less one that’s publicly available. There’s lots of use of the words “can” and “may”. “Must” is used when prescribing what the flow should be *when* a plugin is available.

        In fact, the spec includes example that acknowledge the potential for absent support and encourages content developers to stick to native HTML and JavaScript (in this specific case they’re cautioning against using Java applets with the embed element). This can be found at the very end of 4.8.4 (note that it also specifically prescribes how falling back for a non-Flash-supporting user-agent should be done):

        In the following example, a Java applet is embedded in a page using the object element. (Generally speaking, it is better to avoid using applets like these and instead use native JavaScript and HTML to provide the functionality, since that way the application will work on all Web browsers without requiring a third-party plugin. Many devices, especially embedded devices, do not support third-party technologies like Java.)

        You do not have Java available, or it is disabled.

        My Java Clock

        In this example, an HTML page is embedded in another using the object element.

        My HTML Clock

        The following example shows how a plugin can be used in HTML (in this case the Flash plugin, to show a video file). Fallback is provided for users who do not have Flash enabled, in this case using the video element to show the video for those using user agents that support video, and finally providing a link to the video for those who have neither Flash nor a video-capable browser.

        Look at my video:

        View video.


        So while I can’t specifically point to an explicit statement that browsers need not expose a plugin architecture, and you can’t specifically point to an explicit statement that they must, I do believe that the spec itself demonstrates the acknowledgement that not all browers/user-agents/systems will.

        Consider this as well (and I don’t claim to know the answer; I’m just posing the question): Are console-based browsers (such as links/lynx) inherently non-compliant by definition? Are browsers specifically meant to operate in a purely aural manner non-compliant? I think it’s worth thinking about.


  3. David Moffitt says:

    I was almost starting to agree with a few points until you decided that bringing up the Arizona shootings was somehow conducive to making your point. Really classy move there….

    I will be the first to say I do not like Flash all that much, but I agree that plugins are plugins, and if Chrome is going to support one it should support them all in the same way. What I don’t agree with is a company (Adobe) who has a NON STANDARD freaking scrollbar on their website (that’s pretty much all Flash) claiming that Safari is a “non-standards” browser. Really? Are you kidding us??

    Google and Apple are feuding – not on the same level that you (Adobe) are with Apple right now but they’re both taking turns nibbling at each other’s pies (iAd, Android, lots of overlap now). Hence why Eric Schmidt left, it wouldn’t be appropriate (nor do I think he would have been ALLOWED to stay). Google used the guise of “open” to do nothing more than snub Apple…

  4. Justin D says:

    Whelp, when it’s officially found that WebM violates MPEG-LA’s patent pool, Google’s gonna have to deal with it. And it won’t be pretty. (Never is though, is it?)

  5. Alan Zeino says:

    There is one issue not touched on in this post; what else was Apple to do? Did Adobe ever have a stable, efficient Flash plugin for Mobile Safari during iPhone/iPad development?

    • Matthew Fabb says:

      Alan, Adobe created an organization called the Open Screen Project, specifically to work with companies to make a stable, efficient Flash plugin for various screens. Apple has never wanted to participate. Google did with Android and there’s now a great implementation of the Flash Player for Android devices.

      Meanwhile, people who have jainbroken their iOS devices have managed to install Frash, a port of the Android version of Flash to iOS. It’s still missing some functionality, but I’ve talked to those who have used it and they were quite impressed with it.

    • notboss says:

      Hi Alan,

      That’s an excellent point. The HTML5 proposal describes what a browser should do with plugins but not how it should do it. In the case of mobile browsers I think you can make a strong case that Apple couldn’t just do what they were doing on the Mac. For example having plugins run in the same thread as the browser – the way Safari does (did?) – would be a bad idea on a much less powerful device that must also be a reliable phone. Also, for plugins to make efficient use of a smartphone’s hardware to show video (and preserve battery life) requires some APIs are available to the plugin to facilitate access. So making plugins work well on mobile devices requires additional work on both the browser/mobile device maker and the plugin provider.

      But I think the situation today with smartphones is different than the way cell phones provide limited Web access via WAP and a subset of XHMTL. Apple was claiming it supports HTML5 in its mobile devices and all the rich graphic and video features that come with it. If they do that for things like the canvas tag it seems reasonable to expect them to build a mobile optimized and safer plugin mechanism to accomodate plugins as described by HTML5. I think that’s what Google is doing. If Java, Unity 3D, Silverlight, Flash or some other plugin doesn’t work well in Chrome, the browser will shut them down.

      In simple terms I think browser providers of devices that claim to provide rich visual interfaces according to the HTML5 proposal are obligated by HTML5 to implement some sort of plugin mechanism.

      But perhaps Darryl is right about the language in the HTML docs and I’ve either got it wrong or overstated the case. I’ve obviously interpreted it differently than he has. Even if I’ve got it completely wrong, I still believe that plugins are an essential extension mechanism for the Web that is codified in the HTML standards and proposals.

      For more than a decade people have been creating content on the Web facilitated by the HTML standards of the time – using plugins. Refusing to implement a plugin mechanism in a device like the iPad – so that other people’s content disappears – strikes me as wrong.

  6. notboss says:

    I don’t really understand why John says the video tag was not well considered. (It was over hyped.) I think its a great idea and that there is lots of room for it to evolve over time. I’m not bothered by the fact that you can’t do everything (including DRM) with it. I think over the long term it has great potential and that Google is to be commended for trying to provide a free and unencumbered codec to go with it. I don’t think anyone knows if they will succeed or not – not even Justin D. But I’m delighted by what they are trying to do and wish them well.

  7. notboss says:

    The link from my original comment was lost when it was copied. Here is the full link:

    [jd sez: Thanks… fixed it in the prior.]

  8. Tiny Clanger says:

    Doesn’t the spec say “the user agent *should* use the plugin”, though? (My emphasis)

    “Should” isn’t a requirement – they say “must”. “Should” is a recommendation, but it still indicates it’s optional…

    That said, if I added a plugin for Theora or WebM to Safari, or a plugin for H.264 to Firefox/Chrome, I’d certainly expect it to Just Work with the <video> tag…

  9. Tom says:

    The main article (and a few commenters) seem to think that MobileSafari is not standards compliant because it doesn’t support plugins. Problem with that position is that it’s incorrect. MobileSafari does support plugins, and has since day one. This is how Quicktime media plays on the iPhone, not via MobileSafari, but via a normal plugin that comes preinstalled on every device. And this is how Frash works on jailbroken iOS devices.

    So regardless on your position about Apple and Adobe, claiming MobileSafari is not a fully compliant browser due to lack of plugin support is factually incorrect.

  10. Ian R says:

    John Dowdell,

    It appears a blog post with an impressive patronising contempt for its readers and their collective intelligence has been written and signed off under your name.

  11. John Dowdell says:

    Closing comments on this one, after getting Gruber’d… search on phrase “seagull linking” for more.