Gosh! Compressing WebM Takes FOREVER!

Earlier this week, we realized that we needed to change the template we used for the 2ReelGuys website due to a serious bug in our existing template. So, as we were programming the new website, we picked a template that supports HTML5 video. (HTML5 is a combination of H.264 and WebM codecs to allow video playback in all popular browsers; it is the next version of web video after Flash.)

Well, actually, all Browsers support MPEG-4 files using H.264 codecs except for Firefox, which requires WebM. At which point, things took a turn to the complex.

WebM is an open-source, royalty-free compression codec that is owned and licensed by Google. (It was part of their acquisition of On2 in 2010.) Why Google doesn’t support H.264 is beyond me… the WebM website says that it is because Google wants to foster more open source codecs. (The cynic in me suspects that Google doesn’t want to pay royalties. I also find it interesting that the FAQs on the WebM webpage don’t look like they’ve been updated since about 2011.)

Still, I found myself needing to recompress twenty-two ten-minute programs using WebM. This codec is not available in all compression software, so I turned to Sorenson Squeeze Pro 9, which includes it.


As always, I did a short test encode of about 30 seconds of 1280 x 720 source video to make sure the compressed images looked good. And it took FOREVER! So, long, in fact that I stopped the compression and started doing research. (“Forever” in this case means longer than an hour for a one minute test clip.)

Based on what I read on the web, WebM is noted for its slow compression speeds; especially when compared to H.264. As an example, I can encode a clip in H.264 about 2x real-time; meaning a ten minute clip will compress in about twenty minutes.

However, using the same computer, compressing the same clip in WebM takes more than 10x real time – my ten minute clip was taking more than an hour and showing only 50% complete, when I quit the compression process. Doing more research turned up some custom settings that dropped the compression time – compression times were still really, really long, but at least I could get a couple of ten minute shows compressed overnight. Maybe.

NOTE: I’m doing my compression on a relatively recent iMac, with 16GB of RAM, but without CUDA support. Still, H.264 compresses very nicely on this system, thank you.


I read a another discussion about WebM on the Sorensen website – www.sorensonmedia.com – along with some modified compression settings. I took and tweaked them a bit further to get my images to look good — the original settings caused a lot of artifacting. Here are the settings I used:



Leave all other settings at the default.


When compressing my file with these settings, I was able to compress a one minute test clip about 6.5x real time. So, I can now budget one hour of compression time for each ten minute clip. Sheesh!


Google may think it is doing a good thing by offering an open source, royalty free codec to the market. And FireFox may think it is helping the market by not supporting MPEG-4 or H.264.

But, wow!, creating movies that play in FireFox is wasting hours of my life. I’m going back to compressing using H.264 and let FireFox viewers use a different browser.

Bookmark the permalink.

7 Responses to Gosh! Compressing WebM Takes FOREVER!

  1. Chris Mann says:

    I know some people like to self-host their video, but it’s always been a hassle dealing with different operating systems, codecs, and browsers.

    I just use Vimeo – I just upload one file and my movies play back on anything.

  2. Al Davis says:

    Chris and Larry,
    Using Vimeo and YouTube seem to be popular solutions for not getting bogged down with HTML 5, but they have their downsides. In particular with YouTube (which is free, and incredibly popular); you run the risk of viewers migrating out of your intended website to wonder off with all the side-bar offerings (sometimes your clients competitors if it’s a product or even art). Vimeo charges a fee to get the sufficient upload space (500mb limit for the free version) and frequency of HD publishing. I don’t consider either option as optimal professional practices.
    Also Larry, you leave off having your content viewable on Windows XP, IE8. Hate it? YES! But many hospitals and medical facilities (as well as corporate) still live in that space. Like it or not. There are essential lines of Java Script that you must include with your HTML 5 coding that can miraculously make that happen. Otherwise you must include a Flash wrapper to facilitate that, along with another h.264 file. Thank god we no longer have to produce an OGG file, because they were even a bigger nightmare.
    To your point about Firefox – STUFF IT! I strongly disagree. That may be fine if it’s about Larry Jordan Biz – that belongs to you. I don’t have that kind of latitude with general clients (particularly in the medical field) – who expect their products to show up on all browsers.
    On the idea that WebM is bogus, we agree 100%

  3. Rob van Hoose says:

    I’m a little bug-eyed looking at those settings. Key frame every 10k seconds?? I would probably choose every 2-5 seconds. Also, if you want good quality with fewer artifacts, then generally speaking, don’t do single pass encoding. Variable bit rate is correct, but usually 2 or 3 pass video looks much better than single pass (because if the bit rate is uneven, the codec can give more complex sections more bits and still hit your desired average, which it can only know on a second pass).

    Also, you are telling the encoder to only use 1 thread. Why? Most high performance MPEG2 and 4 encoders “divide and conquer” the video, using as many as 12 threads (if you have a 6 core CPU, 8 threads on a 4-core i7, 4 on a 2-core i7 mobile processor).

    WebM is slower for many reasons, but resulting video is usually almost a third smaller given equal output quality with h.264.

    Consider this, the animated background on the Vimeo website is 10+ mbit/sec WebM/H.264 (both sources). The Webm is 81 megs and the h.264 is around 110. That’s going to make a difference.


    • LarryJ says:


      Interesting comments. I used all the default settings for WebM because I wasn’t sure which to change.

      I’ll take another look at this, given your suggestions.


  4. SLHL says:

    I took 4 days to crack this shit… my project partner and I even had sleepless nights.. trying to solve this. Thanks larry for sharing! great and super neat content btw!

  5. KW Austin says:

    Have you any solution to the YouTube videos problem? Ever since YouTube went to .webm videos, the clips take AGES to download, even MORE AGES to aggregate, and when it’s finally done (yaaaawwwwn) the files don’t play on most of my players, and have a watermark in the top left corner. Your advice it greatly appreciated!

    • Larry says:


      I’ve given up on WebM. I send all my files to YouTube as high-bandwidth H.264 and let YouTube create the WebM versions.

      Have not had any problems or complaints with this workflow. And the speed of compressing H.264 – especially using hardware acceleration is more than satisfactory.


Leave a Reply

Your email address will not be published. Required fields are marked *

Larry Recommends:

FCPX Complete

NEW & Updated!

Edit smarter with Larry’s latest training, all available in our store.

Access over 1,900 on-demand video editing courses. Become a member of our Video Training Library today!


Subscribe to Larry's FREE weekly newsletter and save 10%
on your first purchase.