Share via

HTML5 and Web Video: Questions for the Industry from the Community

A Web without video would be a dull Web and consumers, developers and businesses want video on the Web to just work. As an industry we know this and have, until recently, been on a path to make this a reality with HTML5 by integrating video into Web pages more natively using H.264. There is more detail and discussion below but I want to be unambiguous on some key points:

  1. IE9 will support H.264. Microsoft has released an add-on for Firefox on Windows to support H.264 and today we are releasing a plug-in for Google Chrome on Windows to provide support for H.264.
  2. We will provide support for IE9 users who install third-party WebM video support on Windows and they will be able to play WebM video in IE9.
  3. Many parties have raised legitimate questions about liability, risks, and support for WebM and the proponents of WebM should answer them.

For context, Google recently stated (and then clarified) that their Chrome Web browser would drop support for the H.264 video format in favor of exclusively supporting Google’s new WebM format. There are many thoughtful articles questioning their decision, for example Google's dropping H.264 from Chrome a step backward for openness and The backlash over Google's HTML5 video bet and By dropping H.264, is Google avoiding a trap or walking into one?.

Setting aside the speculation about the reasons and objectives, this announcement has created instability and uncertainty around video on the Web. To get back on track, technical enthusiasts, developers, businesses, and consumers need consistent and sustainable answers to many questions about WebM. These groups also deserve to be part of an open discussion.

Below, we set out the main questions we’ve heard as part of the public conversation with many individuals and groups across the community and industry over the last few weeks and months. Broadly, the questions cover three areas:

  1. Who bears the liability and risk for consumers, businesses, and developers until the legal system resolves the intellectual property issues;
  2. When and how does Google make room for the Open Web Standards community to engage genuinely;
  3. What isthe plan for restoring consistency across devices, Web services, and the PC .

We’ve been clear from the first public demonstration of IE9 that the community deserves a reliable platform for delivering video as part of the modern Web. The goal of this post is to raise the visibility of some of the legitimate questions that the community needs answered from WebM proponents in order for a new technology to become part of the Web standards we all rely on. The climate around intellectual property issues in general and video formats in particular is often highly charged. Anyone suspicious of Microsoft introducing “uncertainty, fear, or doubt” might examine the historical evidence of intellectual property issues around standards and media formats, some of which is covered below. That evidence should leave little doubt that what is needed is a more open dialog about these issues. Our public work on Internet Explorer has made clear our focus on providing the best implementation and validation of established Web standards, helping to move the Web platform forward, and providing the safest and most trustworthy browser for consumers who use Windows.

While this blog is focused on Internet Explorer, we think it is a good forum for a broader conversation about the browsers and technology that the community expects to all work well together. As part of the ongoing transparency in developing IE9, we’re using this forum to put forward questions for the broad community.

Microsoft’s Point of View and Plan for IE9

As context for the questions below, here’s a re-cap of Microsoft’s point of view and plan for IE9.

  • IE9 will play HTML5 video in the H.264 format. Why H.264? It is a high-quality and widely-used video format that serves the Web very well today. We describe many of those reasons in blog posts here, here, and here.
  • Any browser running on Windows can play H.264 video via the built-in Windows APIs that support the format. Our point of view here is that Windows customers should be able to play mainstream video on the Web. We’ve provided Windows 7 customers who choose to run Mozilla Firefox an add-on to enable playing H.264 video on Web pages with the HTML5 video tag. Today we’re making available a similar plug-in for Google Chrome.
  • IE9 users who install third-party WebM video support on Windows will be able to play WebM video in IE. We chose this path (supporting one additional video format that the user has installed on her machine) because we recognize that other video formats exist and we wanted to give customers a convenient way to view video in those other formats without specifying a particular one. With this approach, we provide a more stable platform overall given the many documented risks with arbitrarily downloaded video codecs including their use as vectors for malware and phishing.

Our point of view is totally clear. Our support for H.264 results from our views about a robust Web and video ecosystem that provides a rich level of functionality, is the product of an open standards process like the W3C’s HTML5 specification, and has been free from legal attacks. Microsoft is agnostic and impartial about the actual underlying video format for HTML5 video as long as this freedom continues.

Our commitment to play WebM videos in IE9 for users who have installed WebM demonstrates our approach. We have worked closely with Google to help them deliver a WebM implementation on Windows and Google engineers are on the Microsoft campus this week; we appreciate their positive feedback to date around this work.

Industry Questions

We want to make sure that what becomes a standard can stay a standard and that the standard serves the industry and customers well. An open dialog about the issues that come from new and unproven technology is an important part of how the Web works.

Let’s start with who bears the liability and risk for intellectual property?

Looking at video format support as a vote on who is for or against an open and free Internet is tempting but also naïve. Regardless of the debate on the interplay between patents and video formats for the Web, there is absolute certainty that some parties believe they hold valid and unique inventions (patents) and they will assert those rights if they think they are being infringed. Historically, providing new audio-video-image formats that are entirely free from infringement has been a lengthy and challenging process. Even when we have set out to do this ourselves, we have ultimately ended up being challenged. The targets of lawsuits around the JPEG image format, for example, included a shoe seller, an NFL franchise, and a company best known for its cheese. The real-world risks here apply broadly to many, many companies and agents. Wishing these risks away doesn’t work.

Offers of “free” or “royalty-free” source code and strong assertions that the technology is “not patent encumbered” don’t help when a patent holder files a complaint that your video, your site, or your product infringes on her intellectual property. The only true arbiter of infringement, once it’s asserted, is a court of law. Asserting openness is not a legal defense. Whether one supports open technology or not, there are practical liability issues today that need to be examined. These issues motivate different potential approaches to risk protection. One path is indemnification. For example, will Google indemnify Mozilla, a PC OEM, a school, a Web site, a chip manufacturer, a device company, or an individual for using WebM? Will they indemnify Apple? Microsoft? Will they indemnify any or all of these parties worldwide? If Google were truly confident that the technology does not infringe and is not encumbered by patents whatsoever, wouldn’t this indemnification be easy? It’s one way to move away from conversations about unknown and unbounded risk to a rational conversation about costs and liability. Whether one agrees or disagrees with the notion of software patents, the risk remains and the standard business practice of one party indemnifying another is well-understood. Or, does Google instead plan to protect WebM participants from risk by creating a patent pool containing the third-party intellectual property in WebM and making a license available? That is another way in which risks like this have been addressed in the past. What would the terms of that license be? Or, does Google plan to work with an existing patent pool to help provide Web developers get certainty quickly, as is already the case with H.264? These are difficult questions for sure, but they deserve answers if the Web community is to move from a well-established and successful video format for which the intellectual property landscape is more certain. We think the community is looking for meaningful answers to this risk question.

The risk question is a legitimate business concern. There are hundreds if not thousands of patents worldwide that read on video formats and codec technologies. Our experience with trying to release WMV for free and open use, and the subsequent claims against Microsoft, support this history as do the cases against JPEG, GIF, and other formats. By way of comparison, Microsoft provides and has even expanded the indemnification provided to end-users of Windows. Looking at the notes from a recent “WebM Summit” (here, slide 12), Google says that there are “No known royalty requirements.” That’s quite different from no royalty requirements, and the former might be a more accurate description of the IP situation.

These questions have many potential follow-ups. For example, Google’s blog posts have indicated a strong desire to use open formats for the video tag; will this pattern apply to plugins in general? Will this apply to future HTML5 developments?

Ultimately, Microsoft remains agnostic in terms of HTML5 video as long as there is clarity on the intellectual property issues. To make it clear that we are fully willing to participate in a resolution of these issues, Microsoft is willing to commit that we will never assert any patents on VP8 if Google will make a commitment to indemnify us and all other developers and customers who use VP8 in the future. We would only ask that we be able to use those patent rights if we are sued first by somebody else. If Google would prefer a patent pool approach, then we would also agree to join a patent pool for VP8 on reasonable licensing terms so long as Google joins the pool and is able to include all other major providers of playback software and devices. The entire industry benefits from a significant investment in an ecosystem around a format well insulated from legal issues. As JPEG taught the industry, profitable companies merely wishing IP issues away does not make those issues go away.

Another important question is when and how does Google make room for the Open Web Standards community to engage genuinely?

The WebM specification is not yet an open Web standard by any common definition. Many others (for example, Opera’s blog) have pointed out that this video technology “is not an open standard” but is “actually a good candidate for being turned into a proper open Web standard.”

Google wrote that they “believe the Web will suffer if there isn't a truly open… community developed alternative.” That’s different from their WebM submission to the Internet Engineering Task Force (here), which says the WebM specification is not binding, only Google’s code is: “If there are any conflicts between this document and the reference source code, the reference source code should be considered correct. The bitstream is defined by the reference source code and not this document.” Reverse engineering a standard from sample source code is a poor practice.

The Internet Engineering Task Force’s Web site warns people about referring to submissions like the WebM one as a standard: “some people refer to [these] as ‘standards’ even though the RFCs are not standards, usually to fool the gullible public about something that the person is selling or supporting.”

What are Google’s plans for turning WebM into a genuinely open standard, one that is based on consensus like the rest of W3C’s HTML5 effort? Would Google fully support such an effort? Even the WebM project’s domain is controlled by Google. Google chose to release WebM under the Creative Commons license which would theoretically allow a standards body to use the specification as a basis for a truly open standard. Would Google agree to adopt the specification and changes that would emerge from an open process in a timely and robust manner? What’s the plan and why isn't Google taking the lead?

Until these questions have direct answers, how can the community’s feedback on WebM have an impact? Separating the current implementations from the specification and test suites so that independent implementations are free to emerge from the community and compete and improve is a crucial step that the W3C has taken with HTML5. When will Google enable that to happen for WebM? The community benefits from a robust specification and validation process. The alternative is relying on code re-use and guesses to flesh out an ambiguous and non-binding specification.

In “HTML5, Site-Ready and Experimental,” we described the negative consequences of an unfinished technology (WebSockets) appearing prematurely in a browser. What steps is Google taking to prevent the same failures (e.g., sites that stop working as browsers change, and consumers put at security risk because of premature implementations) from happening here?

Will Google demonstrate their genuine commitment to the open standards process and their openness to community feedback, or will they give some in the community more reason to be cynical?

Lastly, what is the plan for restoring consistency across devices, Web services, and the PC?

Concerns for openness were key reasons given for removing H.264 support from Chrome. Android currently supports H.264 and there are no announced plans to drop it. Will Google drop H.264 support from Android? Is Google committed that YouTube (and other Google video services) will continue to work with devices that lack support for WebM? The lack of consistency across devices, Web services, and the PC is a challenge for the community.

What are the expectations of the hardware community relative to this decision? One of the most recent positive developments around HTML5 has been the ability to take advantage of hardware acceleration, which will not be available in a timely manner if there is a fragmentation in video codec and format support, as hardware development and replacement cycles are significantly longer than software cycles.

Answers Will Help the Community Move Forward

Many people in the community want to hear answers before there’s any more action or commitment. Developers want confidence that what they write will work for consumers. Consumers and businesses want confidence that video on the Web will continue work – and that they will not face legal risk for using it. Google’s decision to drop support for H.264 from its browser seems to undermine these goals.

The questions in this blog post are a start to the conversation we need across the community and industry. It’s a sincere effort to reflect what we’ve heard in many conversations over the past weeks and months about the concerns of developers and businesses. We are sure there are more questions and encourage those commenting on this post to use the forum to air their questions and concerns. If this post has omitted important details or misunderstood the state of efforts of any party, then by all means please correct us. This is a complex topic as evidenced by the broad range of coverage and analysis and so there are many points of view.

Web video is still, in many ways, in its infancy. Working through these questions is part of moving the Web forward. The Web is a product of consensus and open dialog. This post is meant to be part of the dialog.

—Dean Hachamovitch, Corporate Vice President, Internet Explorer

Dean’s comment of 6:33 AM:

"Microsoft pays into MPEG-LA about twice as much as it receives back for rights to H.264." (See Follow Up on HTML5 Video in IE9.)