Mozilla

Video Articles

Sort by:

View:

  1. H.264 video in Firefox for Android


    Firefox for Android
    has expanded its HTML5 video capabilities to include H.264 video playback. Web developers have been using Adobe Flash to play H.264 video on Firefox for Android, but Adobe no longer supports Flash for Android. Mozilla needed a new solution, so Firefox now uses Android’s “Stagefright” library to access hardware video decoders. The challenges posed by H.264 patents and royalties have been documented elsewhere.

    Supported devices

    Firefox currently supports H.264 playback on any device running Android 4.1 (Jelly Bean) and any Samsung device running Android 4.0 (Ice Cream Sandwich). We have temporarily blocked non-Samsung devices running Ice Cream Sandwich until we can fix or workaround some bugs. Support for Gingerbread and Honeycomb devices is planned for a later release (Bug 787228).

    To test whether Firefox supports H.264 on your device, try playing this “Big Buck Bunny” video.

    Testing H.264

    If your device is not supported yet, you can manually enable H.264 for testing. Enter about:config in Firefox for Android’s address bar, then search for “stagefright”. Toggle the “stagefright.force-enabled” preference to true. H.264 should work on most Ice Cream Sandwich devices, but Gingerbread and Honeycomb devices will probably crash.

    If Firefox does not recognize your hardware decoder, it will use a safer (but slower) software decoder. Daring users can manually enable hardware decoding. Enter about:config as described above and search for “stagefright”. To force hardware video decoding, change the “media.stagefright.omxcodec.flags” preference to 16. The default value is 0, which will try the hardware decoder and fall back to the software decoder if there are problems (Bug 797225). The most likely problems you will encounter are videos with green lines or crashes.

    Giving feedback/reporting bugs

    If you find any video bugs, please file a bug report here so we can fix it! Please include your device model, Android OS version, the URL of the video, and any about:config preferences you have changed. Log files collected from aLogcat or adb logcat are also very helpful.

  2. Popcorn Maker 1.0 released – how it works

    This week Mozilla is in London at the Mozilla Festival 2012. A year ago at last year’s Festival, we released Popcorn.js 1.0, and with it a way for filmmakers, journalists, artists, and bloggers to integrate audio and video into web experiences. Popcorn has since become one of the most popular ways to build time-based media experiences for the web. It has proven to be uniquely powerful for bespoke web demos, films, visualizations, etc. This year, we’ve come to the Mozilla Festival with an even bigger 1.0 release: Popcorn Maker 1.0.

    Popcorn.js and Popcorn Maker

    With Popcorn.js, and its plugin ecosystem, we created a tool for developers. Popcorn lets developers work dynamically using timing information from web media, using a simple API and plugin system. With Popcorn Maker we wanted to go further and give this same power to bloggers, educators, remixers, and artists — web makers.

    At its core, Popcorn Maker is an HTML5 web app for combining web media with images, text, maps, and other dynamic web content. Its appearance is unique, but not unfamiliar, providing a timeline-based video editing experience for the web. Once created, Popcorn Maker hosts remixes as simple HTML pages in the cloud, which can be shared or embedded in blogs or other sites. Furthermore, every remix provides a “Remix” button, allowing anyone watching to become a creator themselves by using the current remix as a base project for their own creation. This “view source” experience for web media is a key aspect of Popcorn Maker’s goals as part of the larger Mozilla Webmaker project.

    On a technical level, Popcorn Maker is the combination of a number of separate projects, each heavily influenced by the “12 factor” philosophy: a node.js-based web service called Cornfield; a JavaScript framework for creating highly-interactive web apps; and Popcorn.js, with a set of custom Popcorn.js plugins.

    Coming from Butter

    When we first started we thought we’d create a simple library named Butter, and that Popcorn Maker would be injectable — something you would add to existing web pages, like a toolbar. Many of the original ideas for Popcorn Maker were taken from an early prototype created by Rick Waldron, Boaz Sender, and Al MacDonald of Bocoup. Over time these ideas evolved, Seneca College and CDOT got involved — bringing their heavy experience with web media and Pocorn.js — and more prototypes ensued. Soon it became clear that what was really needed was a full web app: an infrastructure including client, server, and a community.

    This realization occurred as the Popcorn Maker team continued to grow. More developers joined our team some of whom brought much-needed design experience with them. Ocupop was consulted to enhance the design of the project, and gave us the same expertise that was used to produce the branding for HTML5.

    Using LESS for CSS

    Thanks to talented designer-hacker hybrids like Kate Hudson, Popcorn Maker’s design became modern and responsive. We worked with her to integrate LESS — a dynamic stylesheet language which compiles to CSS. LESS made challenges like cross-browser compatibility — something key to Popcorn Maker’s goals — less painful. It also allowed much more flexibility for a rapid prototype approach to our UI. Consequently, a significant amount of our CSS is constructed in functions and stored in variables, both of which are included in files throughout our style implementation. We can make changes that let us try new approaches very quickly, touching and creating as little boilerplate CSS as possible.

    Popcorn Media Wrappers

    Of course, in order to complete the features we desired, we needed to extend Popcorn.js with new features. One such feature is Popcorn Media Wrappers, which wrap non-HTML5 media with an interface and set of behaviours that allow them to be used exactly like HTML5 video and audio elements. By building wrappers for YouTube, Vimeo, and SoundCloud, we were able to standardize all our media code on the HTML5 media interface. More wrappers are in production, allowing more types of media to be included in future releases, and the current wrappers will ship as part of Popcorn.js 1.4 later this year.

    Evolving into a modern tool

    Eventually, Butter and its constituents allowed us to present a full-featured, responsive, end-user tool using nothing more than HTML, CSS, and JavaScript. Currently, Butter uses a modular development environment provided by require.js, and provides a UI toolkit with widgets that were used to build the timeline, scrubber, editors, dialogs and more. In cooperation with require.js’ text plugin, Document Fragments are used to allowed us to build all of our UI in static HTML, and load and render it dynamically at runtime. This approach lets us treat our HTML as it was meant to be treated (i.e., as layout), but also include it in our source tree to be referenced and linted like anything else.

    While building Butter was a large part of the execution of our app, it comprises only a portion of Popcorn Maker. Cornfield, Popcorn Maker’s server, allows users to save and publish their content, completing the Popcorn universe. It uses node.js, Express, Jade templates, and Amazon S3 to provide a RESTful API and hosting environment for Butter. To avoid the thorny issue of user authentication and credential management, Cornfield leverages Mozilla Persona. During development, attempting to use Persona exposed the need to build the express-persona node module to help make Persona work more easily in Express.

    Based on community input

    The Popcorn Maker team owes a great deal of gratitude to its community and users. Their feedback heavily influenced the direction of Popcorn Maker. The most successful and compelling Popcorn.js demos we saw used the video as a canvas, on which to place pieces of the web dynamically. Further, we found that our users wanted to embed their projects — not just host them. These insights were instrumental in moving our focus to creating embeddable content, rather than full-page content.

    Gathering feedback from our users also influenced our development. In Popcorn Maker we’ve experimented with user feedback collection and JavaScript crash reporting, both built directly into the web app. The app’s Feedback button lets users submit general feedback, which is then stored as JSON in S3. Through such feedback we’ve been able to get valuable information about issues users have encountered and ideas for new features.

    JavaScript crash reports

    Even more significant has been our experiment with JavaScript crash reports. This technique is used to great effect with Mozilla’s native development, for products like Firefox and it s crash stats. However, this technique is not often applied to JavaScript web apps. We use window.onerror to detect top-level exceptions being thrown in our code, and present the user with a dialog to allow them to submit an anonymous report, optionally with details about what they encountered. We log various types of edge cases (e.g., null node access in the DOM by wrapping DOM methods) and send this data with the report. This has been an incredible source of data for our team. Since our 0.9 release for the TED talk release we’ve fixed more than a dozen crash bugs, almost all of which our developers were never able to hit locally.

    Influenced by other Mozilla projects

    The development of Popcorn Maker was also heavily influenced by processes used on other Mozilla projects. In particular an emphasis on automation, tooling, and open source best practices. We accelerated our development by using linting in all of our code, from JavaScript (jshint), to CSS (csslint), to HTML, where we created a client-server solution based on the HTML5 parser. We use many automation systems, from botio, to TravisCI, to Jenkins to run our tests and help us trust the rapid pace of code changes. Most importantly, we also employed a two-stage code review process, similar to Firefox’s Peer-Review and Super-Review. By having every patch reviewed twice, we not only reduced regressions, but also helped grow our developer team by ensuring that multiple people understood every change.

    Popcorn Maker has already touched a large community and is the result of the hard work and collective influence of a growing team of dedicated developers, thinkers, and increasingly active community members. We’re incredibly proud to be releasing a year’s worth of work today with the 1.0 launch. The only question left is what you’ll make with it – https://popcorn.webmaker.org!

    More information on the code and development process

    For more info about the code and development team/process:

    Repositories

    Bug Tracker

    https://webmademovies.lighthouseapp.com/projects/65733-butter/overview

    IRC

    irc://irc.mozilla.org/popcorn

    Twitter

    @popcornjs

    Instances

  3. Report from San Francisco Gigabit Hack Days with US Ignite

    This past weekend, the Internet Archive played host to a crew of futurist hackers for the San Francisco Gigabit Hack Days.

    The two-day event, organized by Mozilla and the City of San Francisco, was a space for hackers and civic innovators to do some experiments around the potential of community fiber and gigabit networks.

    Kick-off

    The event kicked off Saturday morning with words from Ben Moskowitz and Will Barkis of Mozilla, followed by the Archive’s founder Brewster Kahle. Brewster talked a bit about how the Archive was imagined and built as a “temple to the Internet.”

    San Francisco’s Chief Innovation Officer, Jay Nath, talked about the growing practice of hackdays in the city and the untapped potential of the City’s community broadband network. The SF community broadband network is a 1Gbps network that provides Internet access for a wide range of community sites within San Francisco—including public housing sites, public libraries, city buildings and more.

    These partners are eager to engage with developers to use the network as a testbed for high bandwidth applications, so we quickly broke off to brainstorm possible hacks.

    Among the proposals: an app to aggregate and analyze campaign ads from battleground states; apps to distribute crisis response; local community archives; 3D teleconferencing for education and medicine; “macro-visualization” of video, and fast repositories of 3D content. Read on for more details.

    Hacking

    Ralf Muehlen, network engineer, community broadband instigator, and all-around handyman at the Archive prepared for the event in a few very cool ways—unspooling many meters of gigabit ethernet cable for hackers, and provisioning a special “10Gbps desktop.”

    The 10Gbps desktop in action

     

    The 10Gbps desktop was a server rack with an industrial strength network card, connected to raw fiber and running Ubuntu. While not a very sensible test machine, the 10Gbps desktop was an awesome way to stress the limits of networks, hardware, and software clients. Video hackers Kate Hudson, Michael Dale, and Jan Gerber created a video wall experiment to simultaneously load 100 videos from the Internet Archive, weighing in at about 5Mbps each. On this machine, unsurprisingly, the main bottleneck was the graphics card. Casual testing revealed that Firefox does a pretty good job of caching and loading tons of media where other browsers choked or crashed, though its codec support is not as broad, making these kinds of experiments difficult.

    Demos

    Here are some of the results of the event:

    Macro-visualization of video

    Kate Hudson, Michael Dale, and Jan Gerber created an app that queues the most popular stories on Google News and generates a video wall.

    The wall is created by searching the Archive’s video collection by captions and finding matches. Imagined as a way of analyzing different types of coverage around the same issue, the app has a nice bonus feature: real-time webcam chat, in browser, using WebRTC. If two users are hovered over the same video, they’re dropped into an instant video chat room, ChatRoulette-style.

    The demo uses some special capabilities of the Archive and can’t be tested at home just yet, but we’re looking to get the code online as soon as possible.

    Scalable 3D content delivery

    As Jeff Terrace writes in his post-event blog: “3D models can be quite big. Games usually ship a big DVD full of content or make you download several gigabytes worth of content before you can start playing… [by] contrast, putting 3D applications on the web demands low-latency start times.”

    Jeff and Henrik Bennetsen, who work on federated 3D repositories, wanted to showcase the types of applications that can be built with online 3D repositories and fast connections. So they hacked an “import” button into ThreeFab, the three.js scene editor.

    Using Jeff’s hack, users can load models asynchronously in the background directly from repositories like Open3DHub (CORS headers are required for security reasons). The models are seamlessly loaded from across the web and added into the current scene.

    This made for an awesome and thought-provoking line of inquiry—what kind of apps and economies can we imagine using 3D modeling, manipulation, and printing across fast networks? Can 3D applications be as distributed as typical web applications tend to be?

    Bonus: as a result of the weekend, the Internet Archive is working on enabling CORS headers for its own content, so hopefully we will be able to load 3D/WebGL content directly from the Archive soon.

    3D videoconferencing using point cloud streams

    XB PointStream loads data from Radiohead's House of Cards music video

    Andor Salga, author of an excellent JS library called XB PointStream, wanted to see if fast networks could enable 3D videoconferencing.

    Point clouds are 3D objects represented through volumetric points rather than mesh polygons. They’re interesting to graphics professionals for a number of reasons—for one, they can have very, very high-resolution and appear very life-like.

    Interestingly, sensor arrays like the low-cost Microsoft Kinect can be used to generate point cloud meshes on the cheap, by taking steroscopic “depth images” along with infrared. (It may sound far out, but it’s the basis for a whole new wave of motion-controlled videogames).

    Using Kinect sensors and WebGL, it should be possible to create a 3D videoconferencing system on the cheap. Users on either end would be able to pan around a 3D model of a person they’re connected to, almost like a hologram.

    This type of 3D video conferencing would be able to communicate depth information in a way that traditional video calls can’t. Additionally, these kinds of meetings could be recorded, then played back with camera interaction, allowing users to get different perspectives of the meetings. Just imagine the applications in the health and education sectors.

    For his hack, Andor and a few others wanted to prototype a virtual classroom that would—for instance—enable scientists at San Francisco’s Exploratoreum to teach kids at community sites connected to San Francisco’s community broadband network.

    After looking at a few different ways of connecting the Kinect to the browser, it appeared that startup Zigfu offers the best available option: a browser plugin that provides an API to Kinect hardware. San-Francisco native Amir Hirsch, founder of Zigfu, caught word of the event and came by to help. The plan was to use Websockets to sync the data between two users of this theoretical system. The team didn’t get a chance to complete the prototype by the end of the weekend, but will keep hacking.

    Point clouds are typically very large data sets. Especially if they are dynamic, a huge amount of data must transfer from one system to another very quickly. Without very fast networks, this kind of application would not be possible.

    Other hacks

    Overall, this was a fantastic event for enabling the Internet Archive to become a neighborhood cloud for San Francisco, experimenting on the sharp edges of the internet, and building community in SF. A real highlight was to see 16-year-old Kevin Gil from BAVC’s Open Source track lead a group of teenaged hackers in creating an all-new campaign ad uploader interface for the Archive—quite impressive for any weekend hack, let alone one by a team of young webmakers.

    From left: Ralf Muehlen, Tim Pozar, and Mike McCarthy, the minds behind San Francisco's community broadband network

    Thank everyone for spending time with us on a beautiful SF weekend, and see you next time!

    Get Involved

    If you’re interested in the future of web applications, fast networks, and the Internet generally, check out Mozilla Ignite.

    Now through the end of summer, you can submit ideas for “apps from the future” that use edge web technologies and fast networks. The best ideas will earn awards from a $15k prize pool.

    Starting in September, you can apply into the Mozilla Ignite apps challenge, with $485,000 in prizes for apps that demonstrate the potential of fast networks.

    Check out the site, follow us @mozillaignite, and let us know where you see the web going in the next 10 years!

  4. FoxIE – a video training series on web standards with Microsoft

    About a month ago Chris Heilmann of Mozilla went to Miami, Florida to shoot a series of training videos with Rey Bango of Microsoft.

    Now these videos are available on Microsoft’s Channel9 as the FoxIE training series.

    In a very off-the-cuff discussion format between Rey and Chris we covered a few topics:

    If you want to present the Mozilla talks yourself, we uploaded the slides in various formats and the code examples with lots of explanations on how to present them to GitHub:

    All the videos are available in HTML5 format and to download as MP4 and WMV for offline viewing.

  5. getUserMedia is ready to roll!

    We blogged about some of our WebRTC efforts back in April. Today we have an exciting update for you on that front: getUserMedia has landed on mozilla-central! This means you will be able to use the API on the latest Nightly versions of Firefox, and it will eventually make its way to a release build.

    getUserMedia is a DOM API that allows web pages to obtain video and audio input, for instance, from a webcam or microphone. We hope this will open the possibility of building a whole new class of web pages and applications. This DOM API is one component of the WebRTC project, which also includes APIs for peer-to-peer communication channels that will enable exchange of video steams, audio streams and arbitrary data.

    We’re still working on the PeerConnection API, but getUserMedia is a great first step in the progression towards full WebRTC support in Firefox! We’ve certainly come a long way since the first image from a webcam appeared on a web page via a DOM API. (Not to mention audio recording support in Jetpack before that.)

    We’ve implemented a prefixed version of the “Media Capture and Streams” standard being developed at the W3C. Not all portions of the specification have been implemented yet; most notably, we do not support the Constraints API (which allows the caller to request certain types of audio and video based on various parameters).

    We have also implemented a Mozilla specific extension to the API: the first argument to mozGetUserMedia is a dictionary that will also accept the property {picture: true} in addition to {video: true} or {audio: true}. The picture API is an experiment to see if there is interest in a dedicated mechanism to obtain a single picture from the user’s camera, without having to set up a video stream. This could be useful in a profile picture upload page, or a photo sharing application, for example.

    Without further ado, let’s start with a simple example! Make sure to create a pref named “media.navigator.enabled” and set it to true via about:config first. We’ve put the pref in place because we haven’t implemented a permissions model or any UI for prompting the user to authorize access to the camera or microphone. This release of the API is aimed at developers, and we’ll enable the pref by default after we have a permission model and UI that we’re happy with.

    %CODEgum%

    There’s also a demo page where you can test the audio, video and picture capabilities of the API. Give it a whirl, and let us know what you think! We’re especially interested in feedback from the web developer community about the API and whether it will meet your use cases. You can leave comments on this post, or on the dev-media mailing list or newsgroup.

    We encourage you to get involved with the project – there’s a lot of information about our ongoing efforts on the project wiki page. Posting on the mailing list with your questions, comments and suggestions is great way to get started. We also hang out on the #media IRC channel, feel free to drop in for an informal chat.

    Happy hacking!

  6. WebRTC efforts underway at Mozilla!

    Last week, a small team from Mozilla attended IETF 83 in Paris, and we showed an early demo of a simple video call between two BrowserID-authenticated parties in a special build of Firefox with WebRTC support. It is still very early days for WebRTC integration in Firefox, but we’re really excited to show you something that works!

    At Mozilla Labs, we’ve been experimenting with integrating social features in the browser, and it seemed like a cool idea to combine this with WebRTC to establish a video call between two users who are signed in using BrowserID (now called Persona). The SocialAPI add-on, once installed, provides a sidebar where web content from the social service provider is rendered. In our demo social service, we show a “buddy list” of people who are currently signed in using Persona.

    The video chat page that is served when the user initiates a video chat uses a custom API intended to simulate the getUserMedia and PeerConnection APIs currently being standardized at the W3C. A <canvas> is used to render both the remote and local videos, though it is also possible to render them in a <video>. We’re working very quickly to implement the standard APIs, and you can follow our progress on the tracker bug.

    A lot of folks burned the midnight oil to get this demo ready before the IETF event, and special thanks are due to Eric Rescorla, Michael Hanson, Suhas Nandakumar, Enda Mannion, Ethan Hugg, the folks behind Spacegoo, and Randell Jesup, in addition to the whole media team here at Mozilla.

    Current development is being done on a branch of mozilla-central called alder. It is going to be an exciting few months ahead as we work towards bringing WebRTC to Firefox. There is a lot of work to do, and if you are interested in contributing, please reach out! Maire Reavy, our product person and project lead for WebRTC would be happy to help you find ways to contribute. Many of us are also usually available in IRC at #media, and we have a mailing list.

    Transcript of screencast:

    Hi, I’m Anant from Mozilla Labs and I’m here at IETF where we are demonstrating a simple video call between two BrowserID-authenticated parties, using the new WebRTC APIs that we are working on.

    This is a special build of Firefox with WebRTC support, and also has the experimental SocialAPI add-on from Mozilla Labs installed. On the right hand side you can see web content served by demosocialservice.org, to which I will sign with BrowserID. Once I’m signed in, I can see all my online friends on the sidebar. I see my friend Enda is currently online, and so I’m going to click the video chat button to initiate a call.

    Here, I see a very early prototype of a video call window served up by our demo social service. Now, I can click the Start Call button to let Enda know that I want to speak with him. Once he accepts the call, a video stream is established between the two parties as you can see. So, that was a video call built entirely using JavaScript and HTML!

    You can check out the source code for this demo, as well as learn how to contribute to the ongoing WebRTC efforts at Mozilla in this blog post. Thanks for watching!

  7. Video, Mobile, and the Open Web

    [Also posted at brendaneich.com.]

    I wrote The Open Web and Its Adversaries just over five years ago, based on the first SXSW Browser Wars panel (we just had our fifth, it was great — thanks to all who came).

    Some history

    The little slideshow I presented is in part quaint. WPF/E and Adobe Apollo, remember those? (Either the code names, or the extant renamed products?) The Web has come a long way since 2007.

    But other parts of my slideshow are still relevant, in particular the part where Mozilla and Opera committed to an unencumbered <video> element for HTML5:

    • Working with Opera via WHATWG on <video>
      • Unencumbered Ogg Theora decoder in all browsers
      • Ogg Vorbis for <audio>
      • Other formats possible
      • DHTML player controls

    We did what we said we would. We fought against the odds. We carried the unencumbered HTML5 <video> torch even when it burned our hands.

    We were called naive (no) idealists (yes). We were told that we were rolling a large stone up a tall hill (and how!). We were told that we could never overcome the momentum behind H.264 (possibly true, but Mozilla was not about to give up and pay off the patent rentiers).

    Then in 2009 Google announced that it would acquire On2 (completed in 2010), and Opera and Mozilla had a White Knight.

    At Google I/O in May 2010, Adobe announced that it would include VP8 (but not all of WebM?) support in an upcoming Flash release.

    On January 11, 2011, Mike Jazayeri of Google blogged:

    … we are changing Chrome’s HTML5 <video> support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

    These changes will occur in the next couple months….

    A followup post three days later confirmed that Chrome would rely on Flash fallback to play H.264 video.

    Where we are today

    It is now March 2012 and the changes promised by Google and Adobe have not been made.

    What’s more, any such changes are irrelevant if made only on desktop Chrome — not on Google’s mobile browsers for Android — because authors typically do not encode twice (once in H.264, once in WebM), they instead write Flash fallback in an <object> tag nested inside the <video> tag. Here’s an example adapted from an Opera developer document:

    <video controls poster="video.jpg" width="854" height="480">
     <source src="video.mp4" type="video/mp4">
     <object type="application/x-shockwave-flash" data="player.swf"
             width="854" height="504">
      <param name="allowfullscreen" value="true">
      <param name="allowscriptaccess" value="always">
      <param name="flashvars" value="file=video.mp4">
      <!--[if IE]><param name="movie" value="player.swf"><![endif]-->
      <img src="video.jpg" width="854" height="480" alt="Video">
      <p>Your browser can't play HTML5 video.
     </object>
    </video>
    

    The Opera doc nicely carried the unencumbered video torch by including

     <source src="video.webm" type="video/webm">
    

    after the first <source> child in the <video> container (after the first, because of an iOS WebKit bug, the Opera doc said), but most authors do not encode twice and host two versions of their video (yes, you who do are to be commended; please don’t spam my blog with comments, you’re not typical — and YouTube is neither typical nor yet completely transcoded [1]).

    Of course the ultimate fallback content could be a link to a video to download and view in a helper app, but that’s not “HTML5 video” and it is user-hostile (profoundly so on mobile). Flash fallback does manage to blend in with HTML5, modulo the loss of expressiveness afforded by DHTML playback controls.

    Now, consider carefully where we are today.

    Firefox supports only unencumbered formats from Gecko’s <video> implementation. We rely on Flash fallback that authors invariably write, as shown above. Let that sink in: we, Mozilla, rely on Flash to implement H.264 for Firefox users.

    Adobe has announced that it will not develop Flash on mobile devices.

    In spite of the early 2011 Google blog post, desktop Chrome still supports H.264 from <video>. Even if it were to drop that support, desktop Chrome has a custom patched Flash embedding, so the fallback shown above will work well for almost all users.

    Mobile matters most

    Android stock browsers (all Android versions), and Chrome on Android 4, all support H.264 from <video>. Given the devices that Android has targeted over its existence, where H.264 hardware decoding is by far the most power-efficient way to decode, how could this be otherwise? Google has to compete with Apple on mobile.

    Steve Jobs may have dealt the death-blow to Flash on mobile, but he also championed and invested in H.264, and asserted that “[a]ll video codecs are covered by patents”. Apple sells a lot of H.264-supporting hardware. That hardware in general, and specifically in video playback quality, is the gold standard.

    Google is in my opinion not going to ship mobile browsers this year or next that fail to play H.264 content that Apple plays perfectly. Whatever happens in the very long run, Mozilla can’t wait for such an event. Don’t ask Google why they bought On2 but failed to push WebM to the exclusion of H.264 on Android. The question answers itself.

    So even if desktop Chrome drops H.264 support, Chrome users almost to a person won’t notice, thanks to Flash fallback. And Apple and Google, along with Microsoft and whomever else might try to gain mobile market share, will continue to ship H.264 support on all their mobile OSes and devices — hardware-implemented H.264, because that uses far less battery than alternative decoders.

    Here is a chart of H.264 video in HTML5 content on the Web from MeFeedia:

    MeFeedia.com, December 2011

    And here are some charts showing the rise of mobile over desktop from The Economist:

    The Economist, October 2011

    These charts show Bell’s Law of Computer Classes in action. Bell’s Law predicts that the new class of computing devices will replace older ones.

    In the face of this shift, Mozilla must advance its mission to serve users above all other agendas, and to keep the Web — including the “Mobile Web” — open, interoperable, and evolving.

    What Mozilla is doing

    We have successfully launched Boot to Gecko (B2G) and we’re preparing to release a new and improved Firefox for Android, to carry our mission to mobile users.

    What should we do about H.264?

    Andreas Gal proposes to use OS- and hardware-based H.264 decoding capabilities on Android and B2G. That thread has run to over 240 messages, and spawned some online media coverage.

    Some say we should hold out longer for someone (Google? Adobe?) to change something to advance WebM over H.264.

    MozillaMemes.tumblr.com/post/19415247873

    Remember, dropping H.264 from <video> only on desktop and not on mobile doesn’t matter, because of Flash fallback.

    Others say we should hold out indefinitely and by ourselves, rather than integrate OS decoders for encumbered video.

    I’ve heard people blame software patents. I hate software patents too, but software isn’t even the issue on mobile. Fairly dedicated DSP hardware takes in bits and puts out pixels. H.264 decoding lives completely in hardware now.

    Yes, some hardware also supports WebM decoding, or will soon. Too little, too late for HTML5 <video> as deployed and consumed this year or (for shipping devices) next.

    As I wrote in the newsgroup thread, Mozilla has never ignored users or market share. We do not care only about market share, but ignoring usability and market share can easily lead to extinction. Without users our mission is meaningless and our ability to affect the evolution of open standards goes to zero.

    Clearly we have principles that prohibit us from abusing users for any end (e.g., by putting ads in Firefox’s user interface to make money to sustain ourselves). But we have never rejected encumbered formats handled by plugins, and OS-dependent H.264 decoding is not different in kind from Flash-dependent H.264 decoding in my view.

    We will not require anyone to pay for Firefox. We will not burden our downstream source redistributors with royalty fees. We may have to continue to fall back on Flash on some desktop OSes. I’ll write more when I know more about desktop H.264, specifically on Windows XP.

    What I do know for certain is this: H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G and survive the shift to mobile.

    Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance. So I am fully in favor of Andreas’s proposal.

    Our mission continues

    Our mission, to promote openness, innovation, and opportunity on the Web, matters more than ever. As I said at SXSW in 2007, it obligates us to develop and promote unencumbered video. We lost one battle, but the war goes on. We will always push for open, unencumbered standards first and foremost.

    In particular we must fight to keep WebRTC unencumbered. Mozilla and Opera also lost the earlier skirmish to mandate an unencumbered default format for HTML5 <video>, but WebRTC is a new front in the long war for an open and unencumbered Web.

    We are researching downloadable JS decoders via Broadway.js, but fully utilizing parallel and dedicated hardware from JS for battery-friendly decoding is a ways off.

    Can we win the long war? I don’t know if we’ll see a final victory, but we must fight on. Patents expire (remember the LZW patent?). They can be invalidated. (Netscape paid to do this to certain obnoxious patents, based on prior art.) They can be worked around. And patent law can be reformed.

    Mozilla is here for the long haul. We will never give up, never surrender.

    /be

    [1] Some points about WebM on YouTube vs. H.264:

    • Google has at best transcoded only about half the videos into WebM. E.g., this YouTube search for “cat” gives ~1.8M results, while the same one for WebM videos gives 704K results.
    • WebM on YouTube is presented only for videos that lack ads, which is a shrinking number on YouTube. Anything monetizable (i.e., popular) has ads and therefore is served as H.264.
    • All this is moot when you consider mobile, since there is no Flash on mobile, and as of yet no WebM hardware, and Apple’s market-leading position.

  8. New features for HTML5 video playback in Firefox

    As explained in this blog post by Jared Wein of the Firefox team there are quite a few new features in Firefox when it comes to playing HTML5 video. As an Aurora user, I am most excited about the option to go full-screen, the ability to overlay video statistics and to save a snapshot of the current frame as a JPG. You can see me talking about and showing them in this short video:

    Firefox has a few features up its sleeve when it comes to HTML5 video playback you might not be aware of:

    • Firefox‘s seeking is now accurate to millisecondsmicroseconds, there is visual feedback when the video has stalled and clicking the whole video pauses and plays it
    • Firefox Beta has specialised controls when you watch video on small devices and watching HTML5 video shows a pleasing background rather than a brutal grey
    • Firefox Aurora has fullscreen, statistics overlay, saving of snapshots and controls appearing when the video ended
    • Firefox Nightly has a full-screen button, fading video controls after 2 seconds of non-interaction, no loading throbber on audio, error reporting when a video could not be loaded on the video, loop attribute support, and resizing of videos larger than the browser window when you watch them directly

    Planned features for Firefox are an overlay play button like YouTube when the video is not set to autoplay and turning off screensavers during fullscreen playback.

    Check out Jared’s post for more information.

  9. Congrats to our July Dev Derby winners on their amazing HTML5 video demos!

    We shifted gears for July and invited Web developers to have some fun with HTML5 video for Dev Derby.

    We had 15 awesome demos submitted and while there was a lot of entertainment and innovation happening, we had to narrow them down to 5 finalists:

    Facial Recognition and Analytics with HTML5’s Video Tag
    HTML5 Video Voting
    HTML5 VJing Tool
    jQuery VideoBG
    Punch the TV!

    There are so many cool things you can do with HTML5 video on the Web, and our winners circle definitely reflects the possibilities. So join us in congratulating our July Dev Derby winners!

    MDN July Dev Derby winners for HTML5 video

    1st Place: HTML5 Video Voting by Jordan Humphreys
    2nd Place: HTML5 VJing Tool by spite
    3rd Place: Facial Recognition and Analytics with HTML5’s Video Tag by dsg (@dsg: Please update your profile with an email address so we can contact you! Thanks.)

    Runners-up:
    jQuery VideoBG
    Punch the TV!

    Thanks to everyone that submitted their HTML5 video demos for the July Dev Derby. On to the next race!

    Right now, there are only a few days left to submit your History API demo for August. And coming up next we have Geolocation for September and CSS Media Queries for October. So start experimenting and hack on.