Media Capture API: Helping Web developers directly import image, video, and sound data into Web apps

Last March, we released a prototype implementation of the audio portion of a working draft of the W3C Media Capture API on HTML5 Labs. This prototype publicized some proposed API enhancements described in section 6.1 of Microsoft’s HTML Speech XG Speech API Proposal. We have now updated the prototype to include the image and video capture features described in the proposal to support scenarios we’ve heard are important for Web developers, as well as incorporating your feedback on audio.

As more and more consumers use mobile devices to take still pictures, videos, and sound clips, Web developers increasingly need support to capture and upload image, video, and sound from their Web sites and applications. A usable and standardized API for media capture means Web sites and apps will be able to access these features in a common way across all browsers in the future.

During this past year, the effort to standardize media capture has intensified. The WebRTC working group was formed and combined scenarios that support basic video and audio capture with the ability to share that media in real-time communication scenarios. A broad interest in both of these scenarios from industry partners and browser vendors alike shifted focus away from the Media Capture API and brought the WebRTC draft spec to the forefront.

This past November, we took our experience with the development of this prototype and interest in media capture for the browser to the W3C's technical plenary meeting (TPAC). Travis Leithead shared some of our feedback with the Device APIs (DAP) Working Group and we continued existing discussions within the HTML Speech Incubator Group. One result of our engagement was the formation of a media capture joint task force in order to bring the best of local media capture and real-time communication scenarios together. We are actively participating in the task force and support the getUserMedia approach to capture.

With the release of this prototype, we give Web developers early access to photo, video and audio media capture APIs in the browser. We anticipate evolving the prototype to share implementation feedback and experience with the new media capture task force. The end goal remains to create the best possible standard for the benefit of the whole Web community.

Let’s also look back at our earlier proposals, explain why we believe the scenarios are still important, and why we implemented them in this new version of the prototype:

Privacy of device capabilities

The prototype allows enumeration of the capture device's capabilities (its supported modes). In the old W3C Device Capture API spec, privacy-sensitive information about the device could be leaked to an application because the navigator.device.capture.supported* properties could be accessed without user intervention. Our prototype moves these APIs to an object that is only available after the user gives permission. The W3C's current getUserMedia API does not support enumeration of device capabilities, but we believe it is valuable to Web developers and should be done in a similar privacy-sensitive manner.

Multiple Devices

The W3C's current getUserMedia API is designed to support multiple devices, either via hints to the API or through user preference. This is an improvement for a scenario that was not supported in the old W3C Device Capture API spec.

Our current prototype also supports a conceptually similar design: navigator.device.openCapture() which returns asynchronously with the capture device the user prefers (through preference or UI).

Direct Capture

In the old Media Capture API spec, the Capture.capture[Image|Video|Audio] operations launch an asynchronous UI that returns one or more captures. This means the user has to do something in the Web app to launch the UI and then initiate the capture, which makes it impossible to build capture UI directly into the Web application. Not only would this be unusable for a speech recognition application, but it is also places unnecessary user interface constraints on other media capture scenarios.

Our prototype and the current getUserMedia capture API directly capture from the device and return a Blob. Note that for privacy reasons some user agents will choose to display a notification in their surrounding chrome or hardware to make it readily apparent to the user that capture is occurring, together with the option to cancel the capture.


For applications like speech recognition, captured audio needs to be sent directly to the recognition service. However, the current getUserMedia API design only supports capturing to Blobs, which delay the ability to process the recorded data.

Our prototype allows starting a capture asynchronously and returning a Stream object containing the captured data. Support for Streams would also be useful in video recording scenarios. For example, using a capture stream, an app could stream a recording to a video sharing site, as it is recorded.


In the case of video capture, live preview within the application is important and something that was missing from the old Media Capture API spec.

Both our prototype and the W3C's getUserMedia API, allow a preview of the recording to be created with URL.createObjectURL(). This URL can then be used as the value for the src attribute on an <audio> or <video> element.


For applications like speech recognition, it's important to know when the user starts and stops talking. For example, if the app starts recording but the user doesn't start talking, the app may wish to indicate that it can't hear the user. More importantly, when the user stops talking, the app will generally want to stop recording, and transition into working on the recognition results. This sort of capability may also be of some use during non-speech scenarios, to provide prompts to users who are recording videos.

Neither the old Media Capture API, nor the current getUserMedia approach support end-pointing.

In order to support key speech/voice scenarios, we recommend adding end-pointing capability. The prototype provides this feature and allows Web developers to experiment and provide feedback on these capabilities which will be useful feedback for the W3C.

Looking Forward

We are supportive of the getUserMedia API, and note that it incorporates many of the points of feedback previously submitted. To avoid confusion about the future direction of media capture at the W3C, the DAP working group has officially deprecated the old Media Capture API, which now redirects to the media capture joint task force's current deliverable.

In addition to a prototype plugin that exposes the modified APIs, we have added to this package a functional demo app that makes use of them.

Building this prototype and listening to your feedback will help Microsoft and the other browser developers build a better and more interoperable Web. We look forward to continuing this discussion in W3C and helping to finalize the specifications.

—Claudio Caldato, Principal Program Manager, Interoperability Strategy Team

Comments (36)

  1. Tinus Guichelaar says:

    Finally some news on this subject. I've waited with developing mobile apps till something like this came along. Now, if only all mobile browsers implemented this tonight..

  2. Dan P. says:

    Are the Media Capture API and WebRTC competing specs or do they complete each other?

    Will IE support WebRTC in IE10 or later?

    Without Flash support in IE10 we need something to implement video chat.

  3. Marcus says:

    @Claudio Caldato & @MSFT – this is your time to shine in a world of standards and the Open Web!

    Which 100% Open and non-DRM-Encumbered format/encoding will the media capture API support for AUDIO and VIDEO?

    If you mention h.264 one more time as your solution for video developers are going to go ballistic! h.264 as has been mentioned only a million !@#$ing times is NOT A VALID OPEN WEB FORMAT!!!!

    Ogg Vorbis for Audio please (and then fix IE to support it natively)

    Web.M (or a new open format for video… that all vendors support NATIVELY out of the box)

    Otherwise – if you can't agree on a format, please for the love of god just drop the API.  We want open standards supported by all – not half-baked implementations in IE only… we learned that lesson already… that's why VML and DirectX Filters are DEAD.

    PS Glad to see that no one at Microsoft has made any effort to fix this broken comment form!  It shows the same lack of commitment that took 10+ years to get .innerHTML to work.

  4. xxx says:


    Unfortunately, the internet is just a very small portion of where video is used. *Outside* the browser, the only viable option is H264 if you want to do something meaningful with video.

    That format has settled down as the industry-norm. We don't want to be thrown back to the dark ages, there are too many format wars out there already.

  5. The inevitable question says:

    Does XG stand for anything? Something Generation? Extended Generality? X-Treme Gerontology? Tell me it's X-Treme Gerontology.

  6. The inevitable answer says:

    XG is the super secret accronym that stands for "Incubator Group" in W3C parlance. If you are among the initiated, you just know. If you aren't, it would take almost three clicks (and a better attention span than a teaspoon) to find out. Which is why it's still super secret.

  7. Slava says:

    Awesome, great news! And please keep insisting on stream based API, we need some movement into live media on a web, not jsut plain old youtube style progressive download html5 media tags.


  8. Plok says:

    Could this in some way allow direct copy/paste of images into rich web editing pages?

    For example, taking a screenshot and pasting it into an email in OWA would be great and immediately useful. If you're not working on a technology that would allow this, please get cracking!

  9. YYY says:

    @xxx: True and Adobe Flash is the only standard to do meaningful interactivity on the web. "That format has settled down as the industry-norm. We don't want to be thrown back to the dark ages, there are too many format wars out there already." :>

  10. @YYY says:

    You neeed to give a shot at visual studio 2011b (beta is free at to create some dynamic movies using ecma-javascript. JS is far more diversified than action script!

  11. @Marcus

    How dare you suggesting WebM as a format over h.264

    WebM is not even a standaard. The V8 video codec in WebM is a propriety format fully owned by Google.

    h.264 is a real standaard.

    It was developed by an industry standard consortium and handed to the independant ISO/IEC standards organization.

    It is fully unacceptable that WebM should be used on the web whilst Google has not handed the VP8 codec to an independant standards organization.

    and even then we should understand that webM is a less efficient codec and has not support in hardware decoding and as such the consumption of WebM video uses a lot more energy than h.264 video. If all of the internet would use webM in the same quality video as we use now then it would cost more than 1000 MWh a year extra energy for computers just to play the WebM video. Also WebM would require extra server and bandwith cost which is also environment unfriendly. WebM is waste.

  12. Mitch 74 says:

    @A_Zune: h.264 is an industry standard, no question about it. It is, however, unusable in a web environment due to its restrictive licensing theme. On the other hand, WebM's licensing allows it to be used in any browser, for any content in any use. See the GIF controversy a while back for a precedent, before a time when any browser was open-source; now that Chrome and Firefox represent more than 45% of the web browser market, you can forget about ever enforcing h.264 as a media standard.

    The complexity of h.264 is also troublesome: most mobile devices for example only accept its Baseline profile, which is not much better (if not worse) than h.263 (yeah, DivX) while desktops can push out and play the Main profile (the real deal in h.264 is CABAC).

    On the other hand, WebM's single profile isn't much more computationally intensive than h.264's Baseline, while approaching Main's quality. Moreover, its origins in VP8 make it very appropriate for streaming capture: it is actually better at still, independent shots than h.264.

    Last, and to give you an idea of how "good" h.264 VS WebM is on the Web, I took a 5 minutes video made using a camcorder on a tripod, containing movements, different lightings, and some panning and zooming, sized at 480×360 px, and packed it using the leading implementation of h.264 (x264) and the latest released version of WebM, with comparable quality settings:

    – h.264 Baseline took up 17 Mb, with compression taking 2 minutes on a 2 GHz dual core making it a 475 Kbit / second stream. While it is usable as an upstream rate in ideal conditions, raising the video's resolution would start pushing it. The CPU time shows that a dedicated chip or a good CPU can handle it.

    – h.264 Main took up 8 Mb, with compression taking almost 4 minutes making it a 224 Kbit/second stream. Half of the above, but for twice the CPU power. And, as said, it can't be read by mobile devices.

    – WebM took up 8.5 Mb, with compression taking 2.7 minutes making it a 238 Kbit/second stream. It is thus computationally close to Baseline, while taking barely more bandwidth than Main.

    Shown side by side, all 3 videos had very similar quality, with ringing or washouts only visible by frame freezing and zooming on all 3 in differing places depending on the strengths and weaknesses of the formats. h.264's intraframes had a tendency to be sharper, but WebM's keyframes were cleaner.

    Note that on such a sensitive thing as video, results can vary a lot; but, real time capture restricts what can be done by quite a lot – using special effects incrustation in real time for example, may show h.264 in a better light. Not everybody is up to doing that though, judging by what people upload to Youtube.

    And, anyway, the implementation will probably end up being codec-independent due to the fact that it would need to be rewritten from scratch the day a new, better codec comes out.

     — Resubmitted: IE team, you should really ask for a better working comment system.

  13. Anon says:


    You are right the comment system is bad.

    Main profile is a joke in terms of quality and compression.

    PC hardware already supports high profile and 'out-of-spec' encodes, pads and phones will soon follow.

    So h264 has much untapped potential (outside of movie piracy circles) which means that it can remain dominant for many years to come.

    There is no need for a new format.


    What does licencing have to do with the end-users (like me)?

    Additionally it has been made clear that web browsers can use system codecs to avoid legal fees…

    I just don't see the problem here.

  14. Mitch 74 says:

    Well, you can use the system's codec to produce the video… However, broadcasting it requires a different license (yup, the MPEG-LA established half a dozen licensing schemes for h.264) – and as such, your OS may have a license to create, store and playback h.264 video files… But it may not have a license to broadcast it. Or to no more than 50 viewers. Or…

    That's part 1.

    Part 2: you're using an OS which can't use h.264: say, webOS, or FreeBSD, or Linux. You're a sysadmin, you'd like to make use of a nice website where they do video conferencing to demonstrate this or that configuration. Too bad, the OS can't support the codec legally: nobody ever built an Itanium h.264 codec with a legal license. Or, you've rooted your DSL box and would like to use it as a nettop. Too bad, it doesn't have a broadcast license either.

    Thus, enforcing h.264 would create a 2-speed Internet: one where users can do video, and the other where users can't do video.

    And before you say "everybody has Windows or Mac OS", please consider those countries where computers are recycled hardware running a free OS, or those who just don't want to run a proprietary OS: athough they represent a measly 1% of the market, this 1% still represents more than 10 million people.

    The Internet must stay open for everyone. If a norm starts relying upon a technology that asks you to pay an entry fee, it's not open anymore.

  15. Neil says:

    Can we please get Microsoft to focus on the underlying matter that is most important.

    h.264 is not viable for the open web – stop pretending it will ever fly as a viable option and focus on a format that will.

    As for your media capture thing (whatever this article post was about) please indicate that it will support an open format for Audio and Video – being SILENT in this blog's comments is equivalent to admitting you have no intention of meeting the needs of developers that are creating sites and applications for the web far and wide on desktops, tablets and smartphones.

    Keep in mind that although Microsoft still has almost 50% of the desktop browser share (globally), MICROSOFT HAS LESS THAN 1% OF THE MOBILE AND TABLET MARKET and therefore has ZERO power in trying to push undesired formats and codecs on developers worldwide.

    Hear us now – loud and clear

    WE HAVE NO INTEREST in h.264 for video formats.

    Please indicate ASAP what your intentions are for supporting a video format appropriate for the web.


    Signed All Web Developers!

  16. @Neil, Mitch74 says:

    I'll start using WebM as soon as Google reimburses me for the $5000 in investments in equipment (vcr, cameras, video, software) I have to replace them for their WebM technology.

  17. Harry Richter says:

    …and I add to the previous comment:

    And second, after reimbursing me, gives me, in a legally binding way, protection from all possible fines, penalties and other hassels that may arise from using patented technology in their WebM technology.


  18. meni says:


    When someone signs as "All Web Developers!", people will be less inclined to take you seriously.

    With that said, I support your cause.

    Here is similar case which make me lose faith in humanity:…/is-apple-is-using-patents-to-hurt-open-standards.ars

  19. meni says:

    Harry Richter, to make this promise we, (ie the free world + Google ;-)) need as good as lawyers as patent trolls, headed by Microsoft have. That's nigh impossible. It's a lost war.

  20. Harry Richter says:

    @ meni

    Calling Microsoft a “patent troll” made me laugh out loud!

    There is one thing that is conveniently forgotten by the self-appointed advocates of so-called FOSS:

    There are laws (in all civilized and most of the un-civilized) countries of the world that regulate the relationships between companies (like Microsoft) and their shareholders. It is laid down in these laws that a company has to do everything to uphold the shareholder value of said company and that also means that they have to defend their intellectual property against the (illegal) use by somebody else (be it other companies or individuals) without paying license fees.

    Were Microsoft not to defend their IP in such cases where this seems to be in the best interest of the shareholders Microsoft as a company and their governing body would make themselves open to lawsuits by their shareholders and rightly so!

    This has nothing to do with the “free world” as you have put it, but simply with adhering to corporate law.


  21. Victor says:

    You can argue all you want until you're blue in the face on WebM vs. h.264 etc. but you're missing the point.

    1.) The Web needs a sustainable format.

    2.) h.264 CAN'T BE IT! – IT DOESN'T MEET THE NEEDS of the OPEN WEB

    3.) h.264 has already failed, by only being supported in 1 browser! (…/HTML5_video) there isn't and won't be any cross browser support for this format

    4.) WebM is at least a lot closer to the ideal web format (it might not be perfect, but heck! there's people that read this blog that have the influence to make it work… just get in a room and work out a solution already!)

    5.) The Internet is now stuck waiting, AGAIN! – Microsoft is the only company and IE is the only browser that are not actively, publicly working towards the common goal of an interoperable format.

    6.) Microsoft was told during IE9 beta development that h.264 would not fly at all and would harm HTML5's success – here we are now in the midst of HTML5's rise to fame and we are handcuffed by Microsoft's unwillingness to accept open standards.

    Thanks Microsoft! Not only did you make us suffer with IE6, but now you make us suffer with IE9+. Stop breaking "the future" of the Internet Microsoft!


  22. meni says:

    Harry Richter, I'm glad I made you laugh. But unfortunately, Microsoft HAS turned into a patent troll. I guess all these suits it received over the years thought it the wrong lesson. Case in point: the suit against B&N. I refer you to:…/microsoft-cites-new-patents-vs-android (there are many other sources, this came up after a quick search). In that view, EVERY browser is infringing on these precious patents. It means, Microsoft willing, every user browsing the web would pay Microsoft for this patented privilege.

    A note to Microsoft employees reading this forum. Does no one object to this? Or are you afraid for your job. This is 2011 you know.

  23. Mitch 74 says:

    @Harry Richter: reimburse a VCR? What for? The only "compression formats" those support is NTSC or PAL. Most SD cameras output a variant of MPEG-2, so no luck here either. For existing videos, you can convert them – that's what most people do anyway. More recent HD cameras do output in h.264, but it's a high bitrate, high profile stream that needs reprocessing anyway. And last, for software, you must have bought lousy software if it can only work on one flux format, and no other. Moreover, h.264 is NOT a good format for video treatment: the use of multiple reference frames alone, on top of the lossy compression scheme, means that any serious video maker won't use it as source for a video treatment job.

    And, finally, there are several hardware makers that now provide h.264 AND WebM-accelerated dedicated chips. Guess why? The WebM spcification is FREE, as is the reference implementation.

    However, a license for hosting and broadcasting h.264 costs an arm and a leg – just ask Google why they decided to convert as many HD videos on Youtube to WebM, it costs less much less to fund, develop and support WebM in its entirety than pay for the MPEG-LA yearly license: $5M.

    @Victor: you should cut Microsoft some slack: at least they allow for the support of WebM in IE, and once made a link to the WebM codec, supporting it somewhat. Apple blocks it in Safari by not implementing it in Quicktime – now there's a patent troll keeping the web back.

    —– Yet again, forced to repost it due to the comment getting scrapped on first submit. If the IE team could please ask for this irritating bug to be fixed in the MSDN blog platform?

  24. Klimax says:

    @meni: It's clear you don't know what patent troll is and do misuse it. (or abuse it)

    Patent troll is company or person who owns patents, but don't manufacture anything and the only way it is earning money is through lawsuits. Patents can be optionally bogus. (Generally used definition; some problems with it as it doesn't deal with some grey areas.)

    Patent submarines are subset of patent trolls, which are waiting until patented technology is in wide use and then it surfaces and starts legal proceedings.

    Sorry, but you are quite mistaken. Including that patent war (don't forget to turn off blinders, they quite distort your view).

    Anything else?

  25. meni says:

    Klimax, sure, you are right. Microsoft isn't a patent troll by its definition. SORRY.

    But how then do you call a company that use to have quite good a portfolio of products, who started collecting patents to use them defensively against trolls, oops, i mean other tech companies, who then somehow got really out of touch with the high-tech world, and is now using its lame patents OFFENSIVELY?

  26. SeanJenkin says:

    Re: Comments on the Blogs Comment system. We have been listening and I realize it's taken a very long time, but today we've rolled out another set of fixes around the comments issues you have been reporting. Hopefully you've seen a lack of duplicate comments the past few weeks. Today we've pushed out bits to fix the submission of the comments along with the time comments can take to load.

    If you still see issues, please use the comment form here ( and report them to me. I'm not watching every IE blog to know when you note issues so please help yourself by getting the feedback to the correct place. 🙂


  27. steve says:

    Thanks @Sean Jenkin – as you are likely aware the IE blog has had issues posting comments for as long as anyone can recall.  I'm glad to hear someone *is* paying attention and attempting to fix it.

    It is also good to see an official contact for the comment form issue as up until now we (a) didn't know there was a contact to use and (b) our only option was to use this comment form which just created a vicious catch 22 cycle.

    now before I click post… the "Vegas Baby" part of me wants to place a wager.  I can see that the post button has *not* been replaced with a simple form.submit(); (the quick and easy foolproof fix) so I'm going to go all in on… "we thought we fixed it but in reality Community Server is just not a good tool for serious blogging" – and thus expecting a failure.

    [CTRL]+[C] (saving a copy before clicking submit), crossing fingers, and…

  28. steve says:

    …wow color me impressed! 1st comment and it actually submitted! (still not convinced but much less skeptical now)

    PS I agree with everyone above – h.264 has got to go, and the new media API's should support an open format by default.  I look forward to hearing Microsoft's response on this matter.  Hopefully they got off the high horse they were riding on when they were shipping the IE9 failure release for HTML5 Video.

  29. Mitch 74 says:

    Don't get me wrong: h.264 is a terrific format, which much higher capabilities in compression/quality ratios than WebM can ever achieve… It is, however, NOT the best format for the web anymore.

    h.264 is well suited for:

    * very high quality, high bitrate video: BluRay, direct download, space-efficient archival.

    * VOD and numerical broadcast systems: the controlled environment and the error resiliency built into the fomat make it very good at that.

    However, its multiple profiles and multiple reference frame encoding make it difficult to use for many tech-savvy users and inappropriate for real-time web use.

    WebM is well suited for:

    * open to closed environments, with differing licensing schemes

    * web broadcast and playback, due to its low demands in decoding power, very good single image compression ratio, reasonable bitrate requirements, and more recently, resilience to dropped/corrupted packets.

    Trying to submit a comment in a single go… FAILED!

    Submitting a second time… OK.

  30. Anon says:


    One of the MAJOR reasons WebM exists is because Google wants to maximize its profits.

    This is probably the reason IE9 allows 3rd party codecs like WebM as well.

    Switching to WebM would be profitable for companies.

    Companies are not people, so stop advocating for their rights.

    As long as I do not have to pay to play videos, I see no problem.

    "accept open standards."

    Why do people keep throwing this word "open" around?

    A browser like Firefox is CLOSED OFF to WebM only.

    You cannot play h264 in Firefox without Adobe.

    If we define "open" as FORCING A FEW ELITE FORMATS, we start making "In Soviet Russia, .." jokes.

    To elaborate, yes lets make the Internet open & free by forcing WebM unto everyone.

    "lot closer to the ideal web format"

    It is still a joke compared to h264.

    If WebM was better than h264 (best is 10bit high profile h264 AFAIK) then by all means go WebM.

    But for now, STOP pushing WebM – PROVE its potential first!

    A good example is MP3.

    Yet everyone still uses it, but is not the best

    and thus I do not support it.

    "WE HAVE NO INTEREST in h.264 for video formats."

    Please do not say "we", as "we" doesn't include DXVA-dependent people (weak CPU / netbook) and people that want the best quality with least bandwidth.

    "webOS, or FreeBSD, or Linux"

    I for one expect to get more 'kick' out of something I paid for than from something free.

    Thats really my whole argument; services that you paid for (Windows, Mac) are supposed to offer more.

    WebOS has been dropped by HP AFAIK. Linux has never been marketed as a multimedia OS.

    And, I sorry, but I do not know that FreeBSD is.

    "2-speed Internet: one where users can do video, and the other where users can't do video"

    Which can be solved by using Adobe Flash Player?

    It provides video playback for lesser OS, such as Linux.

    IPad just support HTML5 h264 avoiding Flash Player.

    "still represents more than 10 million people"

    And IE9 is not availabe for XP, yet you are on a blog about IE10/IE9.

    This also applies to the above.

    Do not use an argument which makes you a hipocryte 🙂

    "h.264 has already failed"

    This statement is insane – pure rubbish which discredits you completely.

    BluRay? High Definition Video Streaming, Camcoders, Windows 7, Apple Products, Adobe Flash Player, Silverlight?

    VLC, Media Player Home Cinema, FFDShow, LAV CUVID, CoreAVC?

    Camcoders? Anything professional?

    A PC requires h264 support otherwise you can't do the most basic thing like play a BluRay.

    "h.264 would not fly at all and would harm HTML5's success"

    How would using a common place format that is fully hardware accelerated and offers awesome compression hurt?

    "several hardware makers that now provide h.264 AND WebM-accelerated dedicated chips"

    So… who is going to pay for my new computer with this WebM hardware?

    Or should the world just shun these poeple who were used to playing HD web videos (DXVA) and tell them to go back to SD (CPU)?

  31. Klimax says:

    @meni 12 Dec 2011 11:31 AM:

    I'd say agressive defense of their IP.(using patent system as designed and maintained; that's why it needs some reform – And considering Google's attitude, this situation was quite predictable… No, Google didn't help their partners at all by ignoring potential patent disputes and relevant patents)

    BTW:Check out these articles (Apple may be using patent troll to do its legal dirty work) or (Is Apple using patents to hurt open standards?)

  32. Mitch 74 says:

    "Open" in this context means "that everyone can use, disregarding hardware, software, licensing,language or intended use". The license used for WebM comes very close, as you are not limited to the hardware (h.264 either), software (technically, due to x264, h.264 isn't software limited), licensing (for h.264, you must buy a licensed decoder, you must buy a licensed encoder, you must buy a broadcast license, you must buy a storage license… The list is long).

    "Firefox is closed off WebM": it supports it natively. It is possible to add h.264 support to Firefox, but that requires gluing an additional codec to it; using the system's codec infrastructure would indeed be possible, but then you can say goodbye to sandboxing. The other solution, that of offering a Firefox plugin for h.264 support, has been done by Microsoft… For Windows only. They would need to license each and every copy distributed on other OSes, so they won't do that.


    "Linux has never been marketed as a multimedia OS": now, sorry, i call b**s**t: pretty much all set-top boxes, DVD/BluRay players, multimedia hard disk recorders sold nowadays do run under Linux. And, if you didn't get a copy of the GPL license (more often than not, hidden in a corner of the disk or at the bottom of the EULA), please mention it to the Free Software Foundation – as that is illegal,as in "breach of copyright". However, the hardware maker paid the MPEG LA for your using it – and passed it along with the product's price. On desktop Linux, you can actually buy such a license for a few bucks and get a perfectly legal codec, including BluRay decoding. You can get some for free, but then THAT is illegal in several countries.

    It's funny that you mention VLC: this player can support it out of the box because it is hosted and initially developed in France, where licensing and patent laws are still not as crazy as in the US (although it's getting there) and a license on a format "must allow for interoperability" – thus allowing clean room reverse engineering and implementation from specs for MPEG-1,2,4 in both audio and video (MP3 is MPEG-1 Audio Layer 3). However, using it on a machine that doesn't have an MPEG-4 license in the US is, in essence, illegal. But, since it's quite rare, the MPEG-LA isn't tracking those users of Windows XP with a quad core and who never bought a DVD player that just happened to come with an OEM version of this or that video player – which, incidentally, paid for that license.

    Last, I'd like to ask: what's the limitation in buying what you need? Is it your wallet, or is it the concept? If you can't understand the latter, then you can't understand why some would want to use WebM – or, WHATEVER FORMAT that allows:

    * using it the way you want,

    * using it for whatever you want,

    * adding it to your own software or hardware,

    * improving it as you need.

    —– again, trying to sumit… FAILURE! Resubmitting…

  33. Anon says:


    Again, I ask you, why does this matter to the end user?

    Apple and MS will continue h264 support.

    You really need to read this as well:


    MPEG LA announced today that its AVC Patent Portfolio License will continue not to charge royalties for Internet Video that is free to end users (known as “Internet Broadcast AVC Video”) during the entire life of this License. MPEG LA previously announced it would not charge royalties for such video through December 31, 2015 (see…/n-10-02-02.pdf), and today’s announcement makes clear that royalties will continue not to be charged for such video beyond that time. Products and services other than Internet Broadcast AVC Video continue to be royalty-bearing."

    h264 is free/open in a sense that actually matters to any end user (royalty-free).

    So please stop all the FUD, it is not helping the future of the Internet.

    "say goodbye to sandboxing"

    Very bad example, Firefox doesn't sandbox. IE9 is way more secure.

    Firefox simply refuses to support h264 on basis of well… arrogance.

    Additionally how would using system codecs compromise anything?

    MS plugin leaks memory AFAIK.

    "They would need to license"

    Not if you allow Microsoft DTV-DVD codec on the codec whitelist.

    "i call b**s**t"

    Company's problem.

    "buy such a license for a few bucks"

    Will be cheaper than buying Windows.

    "US is, in essence, illegal"

    You are misinformed.

    Not 2015 yet so fully legal like every other player/h264 codec out there.

    Now for the last point:

    GPU supports 50+ Megabit h264; great HD movie build… or I can run 480p WebM.

    Long time investment – web aint at 50+ Mbit h264 streaming video.

    My philosophy is simple – progress not anti-progress:

    – DXVA not CPU (all GPUs support h264 now, some since forever ago)

    – High compression not low compression (clearly h264)

    – High quality not low Quality (clearly h264)

    – Good Software Decoding Speed not Bad Software Decoding Speed (CPU: 720p h264 vs 480p WebM)

    – 3D Video (I haven't even heard WebM mentioning this!!)

    So, I cannot accept this malicious Google anti-h264 propaganda.

    — Tried submitting in Opera, failed. :/

  34. Well I work with video surveillance and everything is h264.  And it cannot be upgraded because they all use customer encoder chips.

    I use h264 for everything…. and I'm fine with that.  I spent years dealing with mjpeg, h263 + variants, mpeg 4 + variants.  You support all that crap and then say we really need another codec….  H264 has fixed all that and it's well supported.

    WebM is trying to compete on price with something that is already free as far as most people are concerned.  And h264 is better and already supported by everything.

    Would you pay $1-5 to have all the videos you watch on the internet stream faster and look better?  And work with your existing phone, tablet, and pc?

  35. Anne says:


    Q.) Is Microsoft is fully committed to natively supporting an open video format for HTML5 Video playback AND the Media Capture APIs?

    [__] Yes

    [__] No, Microsoft intends to further ruin the future of the Web by only supporting h.264 – an invalid option for HTML5 video


  36. Klimax says:

    @Anne: Wrong question/answers pair. (Attempted false dilemma and malformed question of type "have you stopped beating your wife") Better to ask this way:

    Will Microsoft support any other formats beside H264?

    1)Yes. //Small exceptions (workaroundable)

    2)No. //No interest,…

    3)Yes, but… //condition – like patent are cleared,… ; similar to maybe

    4)Through framework like MediaFoundation

    This is much better for discussion and possible answer – but you don't have to ask! They have already answered it when developing IE9:…/html5-and-web-video-questions-for-the-industry-from-the-community.aspx…/follow-up-on-html5-video-in-ie9.aspx…/html5-video-update-webm-for-ie9.aspx…/html5-video.aspx

    And they would state if there was change. (Also lawyers might have say as this could easly get MS sued again.)

Skip to main content