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.
COMPRESSING WITH WEBM
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 two 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.
MODIFYING SETTINGS
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:
WEBM VIDEO – SIMPLE MENU
IN THE COMPLEX MENU
Leave all other settings at the default.
VORBIS AUDIO
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!
CONCLUSION
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.
5 Responses to Gosh! Compressing WebM Takes FOREVER!
“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.”
+1. This is the same conclusion I come to every time my web team suggests moving to WebM from h.264. A few tests with it reconfirm my dislike for it as a delivery format. Couple that with Google’s apparent lack of development/refinement for it and I’ll stick to h.264/265 for the foreseeable future.
Yeah, it’s not worth the effort Larry. I just looked at our stats and Firefox usage peaked in 2009 (at 27%) but has been declining ever since. Currently running at 16% of visitors on Firefox vs 28% on Chrome and 49% on Safari.
In fact H.264 will be coming to Firefox next year…!
http://gigaom.com/2013/10/30/mozilla-will-add-h-264-to-firefox-as-cisco-makes-eleventh-hour-push-for-webrtcs-future/
Hi Larry,
I don’t have Sorerson to compare speed/quality but when I had to supply a project in WebM I stumbled across firefogg.org which is an extension for the Firefox browser. Once installed, it offers a simple interface within the firefox browser to select a file and transcode settings – preset or advanced.
On my 2008 MacPro it doesn’t seem much slower than real time although I do have a nVidia GTX570 Cuda card fitted – but I’m not aware of whether Firefogg is using Cuda.
I was using a ProRes 1080 source and outputting to 720P.
I do however agree with everyone else that in this day and age it seems unnecessary to be encoding in different formats for browser compatibility. Roll on h.264 for firefox!
Hi Larry
After reading your article I came across this post and thought it might be another option.
http://www.eoshd.com/content/11534/new-h-265-codec-test-prores-4444-quality-1-file-size
Neil:
H.265 is brand new. It is principally designed to reduce file sizes for video delivery over cellular networks. While I am not as enthusiastic about it as the author of this report, it does have significant promise — but NOT for editing, only for acquisition and delivery.
Larry