Tag: webm

Encoding WebM Videos

by Jeroen Wijering on 2012-03-06 11:02

WebM is coming up on its second anniversary. Released by Google as a royalty-free alternative to MP4, the video format has slowly gained traction on the web. MP4 still rules by a wide margin, but WebM has dethroned Ogg as the other leading format for HTML5 video.

This post describes two tools for encoding WebM videos: a desktop client and a cloud service. Both are free, easy to set-up and painless to understand. Which one you choose depends upon your personal preference - or the restrictions your company's IT department imposes.

Desktop Encoding

For desktop encoding, Firefogg is the best option. It is not a standalone tool, but an addon for the Firefox web browser. If you have Firefox installed, go to Tools » Addons to search for and install Firefogg. If you don't have Firefox, get it here.

With Firefogg installed, go to Tools » Make Web Video to start an encode. Now select your original video, select your output preset (360p is a good one) and click encode. Firefogg starts crunching and minutes later your WebM video will be done.

Select Advanced Options in step 2 to customize the video Size and the audio/video Quality. The sweet spot for video quality seems to be 7 (smallest file without artifacts). The sweet spot for audio is 3 (112 kbps). Be sure not to change any of the other options, unless you know what you're doing!

That is it on the desktop side - short and simple. Firefogg may not have the best looks, but it gets the job done. If you're looking for something more professional, check out Sorenson Squeeze. It has many more options, but is also not free.

Now let's go online. Our very own online video platform, Bits on the Run, is easy, free and capable of WebM encoding. Sign up for a Free Account and log-in to the dashboard. Go to Account » Settings » Templates and click Add new Template to create an encoding template. Set the format to WebM Video.

On the next page, set the Target width to 480 pixels and the audio/video quality to the good tradeoff option. This gets you the same results as the Firefogg settings above. Next, set the Automate option to Automatically apply, so your WebM video are automatically built every time you upload a new original. Save the template.

Now go to the Videos section to upload an original video. When the upload is complete, go to the Transcodes tab to see the encoding progress. Your WebM template is listed here. When the WebM transcode is done processing, you can click its yellow Publish icon to copy/paste its URL, or to download it to your computer.

Like Firefogg, Bits on the Run provides a basic encoding interface with only the essential controls. A dedicated transcoding service like Zencoder.com offers many more options, but is also much harder to use.

The End Result

If you're reading this post in Chrome, Firefox or Opera, the resulting WebM video can be seen below. It is embedded using this JW Player setup. The unavoidable MP4 version is encoded separately, so Internet Explorer and Safari users are not left out:

Download the WebM video here

That is all for now! Much more info can be found on the WebM project site. In particular, this page has a wealth of information about encoding parameters. Visit their blog for news on hardware, software and ecosystem support.

Comments (1)   Tweet   Share

HD Video Everywhere!

by Jeroen Wijering on 2011-08-24 02:05

These days, HD quality video is no longer an option - it is essentially a requirement. On the other hand, there are still quite a few viewers out there that are unable to play high quality video, due to connection or device constraints. A simple way to fix this is by offering an HD toggle in your player. Viewers that want the full experience select the high quality option, while viewers that don't have the capabilities (or interest) select the low quality option.

With a combination of some thoughtful encoding and the HD plugin for JW Player, creating such a setup is very easy. This post explains how to encode for and embed a player with an HD toggle that works on the desktop, as well as on the Android, iPad and iPhone. We'll even discuss how to support HTML5 everywhere by including a WebM HD toggle.

HD video on Chrome/Windows, the iPhone an Firefox/Mac.

Encoding

First, we have to render two versions of our video: an HD one and a lower quality one. Since the iPad, the latest iPhones and Android flagships - like the HTC Desire and Samsung Galaxy S - all play 720p video, let's use that as the HD version. Full HD (1080p) is still a bit overkill, in my opinion.

For the lower quality version, it's best to stick to settings that older phones such as the iPhone 2G/3G, HTC Legend and Motorola Droid can play. For example, 270p will work fine. At this size, we can also have the video play without stutter over a 3G connection. Plus, even those rusty 5-year old laptops should be able to play the clip.

Here's a quick overview of the main encoding parameters for our video. For more details on the encoding side, check a previous blog post about supporting mobile video on your site.

Embedding

With the two versions of our video encoded, let's move on to embedding. In addition to the two MP4 files, you must also upload jwplayer.min.js and player.swf (available on the JW Player download page), as well as a nice still image (JPG) from your video. Note: we recommended the JPG as the video image - just for good looks. Next, include the player in the <head> of your HTML page:

<script type="text/javascript" src="http://example.com/jwplayer/jwplayer.min.js"></script>

With the player included, move on to place the actual embed code:

<div id="container">HD video coming up!</div>

<script>
var options = {
    file: "/assets/video-270p.mp4",
    height: 270,
    modes: [
        { type: "html5" },
        { type: "flash", "src:/jwplayer/player.swf" }
    ],
    plugins: {
        hd: { file: "/assets/video-720p.mp4" }
    },
    width: 480
};
jwplayer("container").setup(options);
</script>

With this setup, the player is setup into the <div> when the page loads. The 270p video is loaded into the player by default. The HD plugin is used to offer a toggle to the 720p video. This toggle is:

• Displayed as a button in the top-right of the video on desktop browsers. Viewers can click the button to enable and disable the HD version.
• Displayed as two big buttons in the middle of the video on Android and iOS. On their small touch screens, viewers can easily see and click these buttons.

WebM Support

Note the modes block in the above embed code define which playback mode is used first: Flash or HTML5. In this case, HTML5 is used first, because it enables the video to resume after doing an HD toggle. When clicking the HD toggle in Flash, the video will re-play from the beginning.

Unfortunately, not all HTML5 browsers (Firefox / Chrome ^† ) support the MP4 files we use. The player will therefore fallback to Flash. In order to profit from HTML5 playback in these browsers too, you should do two additional WebM encodes of your original video. You can use the same dimensions and bitrates as for an MP4.

On the embedding side, we add one small check. In between defining the options and setting up the player, we sniff if the browser is able to play WebM video. If so, we swap out the MP4 files for WebM ones:

...
    width: 480
};
if(!!document.createElement('video').canPlayType('video/webm')) {
    options.file = '/assets/video-270p.webm';
    options.plugins.hd.file = '/assets/video-720p.webm';
}
jwplayer("container").setup(options);
</script>

Now you're all set! Glorious HD video in HTML5 mode, on every browser and device that matters. Check out the live example:

example

† Though Chrome announced they would drop MP4 support last year, it is still working in the current version (Chrome 14).

Comments (4)   Tweet   Share

FOMS: Funny Name, Serious Talk about HTML5, Bitrate Switching, WebM, and WebSRT

by Zachary Ozer on 2010-10-08 13:25

Last week, in the midst of our normal support requests and software development, we found a way to squeeze in a little extra time to attend the Open Video Conference and associated meetings here in New York. Everyone here at LongTail is a strong believer in open media formats, but it is rare to see so many people who are as committed to it as we are - assembled in one place.

For most of us, the most exciting part of this whole week was the Foundations of Open Media Software Workshop, organized by Silvia Pheiffer, a member of Xiph.org and frequent contributor to the HTML5 media specification.

Bitrate Switching

Going into the workshop, we were especially interested in hearing everyone’s thoughts on adaptive bitrate switching. While this is one of the most popular features of our Flash player, HTML5 doesn’t offer any mechanism for handling this, so we can’t offer this functionality in our HTML5 player. Thankfully, the workshop included a brilliant mix of browser vendors (Philip Jägenstedt from Opera, Chris Blizzard from Mozilla), Codec designers (John Luther of WebM and Christopher “Monty” Montgomery, Gregory Maxwell,Timothy Terriberry, and Ralph Giles of Ogg Theora and Vorbis), and player developers (Steve Heffernan of VideoJS, Michael Dale of Kaltura).

Several viable alternatives were presented for bitrate switching, however, there are several technical challenges to contend with. First, there is a question as to whether to use several long files and simply switch between them using range requests, or to break the files up into thousands of short (~5 second) "chunks", and play them back sequentially. Ultimately, using several long files presents a big challenge, both in terms of time to start playback and live streaming. All current file formats would require that the index of switch points be loaded for all files before starting the video. This dramatically increases the amount of time required to begin playing back a video and makes live streaming impossible, since the index could not be dynamic. Additionally, while a new file format could be designed to handle this, it would be difficult to achieve widespread adoption.

This meant that a mechanism that used several manifest files and many small files seemed quite attractive. The browsers would simply load the manifest for the appropriate quality, and then load a different manifest if necessary. Furthermore, the browser could periodically check for additional entries in the manifest, effectively allowing for a livestream with DVR. The browser vendors noted that this could be very simple: they will need to implement a mechanism for synchronizing media playback over multiple files for accessibility (alternate audio tracks) regardless, so why not use this to simply stitch together video files, one after another? Finally, this mechanism closely mimics Apple's bitrate switching mechanism, so it has a proven track record, and the tools built to support it.

Unfortunately, the format discussion was so involved, it left little time to discuss how the browsers would choose to switch streams. A loose JS API was proposed for this, with the possibility that browsers would build in their own default logic. However, based on this feedback from the group, we will draft a specification for this, post it for feedback, and include it in the JW Player as soon as possible.

WebM

One of the other highlights was the community’s interest in WebM. Much of the video on the web today relies on the H.264 for encoding video. Unfortunately, H.264 cannot always be used without paying royalties to a licensing organization, MPEG LA. While the HTML5 video spec was being developed, Ogg Theora was the only realistic open source alternative to H.264. Unfortunately, it’s performance is not nearly as good as H.264. WebM is a project that was started up by Google after their acquisition of ON2, which offers a high-performance, royalty-free codec for video. For this reason, the participants were especially interested in the possibility of adopting it as the baseline codec for HTML5. In fact, our HTML5 player already supports it, as both Opera and Chrome have this functionality built into their production browser, and Firefox has it available in their new beta. The biggest concern was that Apple and Microsoft have both refused to include support, and while Adobe recently announced VP8 support, there have been no dates set.

WebSRT

Finally, there was a discussion over web accessibility, specifically subtitles and closed-captions. This is near and dear to our heart, as JW recognized the importance of this early on, and made sure to include accessibility functionality ever since. The new standard for subtitling and captioning on the web will likely be WebSRT, and we’ll be working closely with the drafters of that specification and browser vendors to include support as soon as possible.

As intellectually stimulating (and fun) as these workshops are, it’s important to us that we’re a part of these discussions so that we can continue to develop the most innovative products, and that those products are standards based. So keep your eyes peeled – we’ll be working hard to integrate these technologies into all of our products as the standards develop.

Comments (2)   Tweet   Share