Taking webm for a Spin
I first blogged about webm the day Google released it. It has taken some time but now I have full support for webm in my preferred Linux desktop distro (Fedora 13). I've been doing some testing and I have to say I'm impressed.
Why even care about webm? Because I prefer to use royalty-free file formats that are based on open standards and free / open source software. Any other questions? :)
I'll cover both webm playback and encoding.
As you may recall, several of the web browser makers also announced upcoming webm playback support in their next major releases. So far as I know, Opera is the only browser vendor thus far that has released a production version that includes webm support (Opera 10.6). Firefox and Chrome do offer webm support in their beta releases.
How about standalone media players? The day webm was released Google included patches for mplayer, VLC, and gstreamer. The first pieces to appear in Fedora were updated gstreamer packages as well as the addition of a libvpx package. As a result any player that offers gsteamer-based playback (like Totem) can play webm videos. Fedora doesn't include mplayer nor VLC in their official repos due to patent-related issues but both are available in the third-party RPMfusion repo. VLC released version 1.10 that includes webm playback support but so far rpmfusion has not released an updated VLC package. Luckily rpmfusion has released an updated mplayer package with webm support.
On webm release day Google also offered patches for ffmpeg to add webm and VP8 support. Not long after, the ffmpeg developers released an update that, among other things, included webm support. Again, due to patent-related issues, Fedora does not package ffmpeg and rpmfusion does. Last week rpmfusion released updated ffmpeg packages. I've been using ffmpeg for encoding for some time so getting into webm was going to be a breeze.
What do I use to test out webm? Since I already have quite a few avi videos I decided to convert some of them. I was amazed at the quality of webm conversions but realized that medium quality avi files aren't the best source material.
How about DVD quality video? How about Sita Sings the Blues? That sounds like a no-brainer as it is a freely distributable movie with very high quality source files available.
I ripped the movie from the video DVD iso image with mencoder using a command line like:
mencoder -dvd-device Sita_Sings_the_Blues_DVD_NTSC.iso dvd://2 -ovc copy -oac copy -o Sita_Sings_the_Blues.mpg
Then I converted it to webm using a command line like:
ffmpeg -i Sita_Sings_the_Blues.mpg -f webm -b 2500k -ab 128k Sita_Sings_the_Blues.webm
If you have ever used ffmpeg you'll know its syntax is pretty easy to pick up and the ffmpeg man page is fairly complete so I won't spend any time giving an ffmpeg tutorial. The "-f webm" part tells ffmpeg that you want the output video to be in .webm format and it automatically uses the VP8 and Vorbis codecs without them being explicitly specified.
I have done subsequent conversions using a number of bitrates and resolutions.
Not so Fast
The webm encoding speed isn't so great though. Encoding a video takes significantly longer that I'm used to for avi or other formats? How bad is it? I'd say that it is at least 1/2 to 1/10th the speed depending on what I compare it to.
Google is actively soliciting for community developers with specific emphasis on optimizations so I only anticipate that webm will improve speed-wise as development progresses.
Playback and resource usage are fantastic except for a bug with large files that I mention below.
One Bug of Note
I have noticed one problem though and that is with large .webm files. The current crop of video players seem to periodically stutter and become jerky. At first I thought it might be a resource issue with the computer hardware but when the jerky playback happens there are plenty of free resources and the standalone video player is only using 10% or less of the CPU.
To isolate the problem I did a few tests where I'd move the playhead to a spot in the full-movie .webm file where jerkiness was observed and make a note of the time. Then I'd cut out that chunk of the video into a separate file with a command like:
ffmpeg -i Sita_Sings_the_Blues.mpg -ss 3120 -t 300 -f webm -b 2500k -ab 128k Sita_Shorter_Sample.webm
That produces a 5 minute video starting at 52 minutes in. Playback was fine on the smaller file so the problem is not the result of a bad encode or in the complexity of the video causing performance problems.
I have used multiple computers with different video cards and the bug is consistent so it doesn't seem to be hardware related. I guess it is bug in the indexing or buffering code and I have filed a bug report with the Fedora bug tracker. We'll see how that progresses although the bug report may have to be refiled upstream.
I'm in the middle of doing additional testing where I take a large file and chop out a section of it to a smaller file. I started with a 15 minute selection. I'm going to test each new encode and if it isn't choppy, add another 15 minutes to it and test again... to see at what size/length the playback becomes choppy. I'm up to 45 minutes now, which wasn't choppy and just started a 60 minute encode. I'll update this when I get it figured out.
So far I'm very impressed with webm and the VP8 video codec. We already knew the Ogg Vorbis audio codec was excellent. I'm in the process of converting my avi library to webm files and am optimistic that the encoding speed will improve in the not too distant future... but if it doesn't happen I can live with it. Assuming the bug I reported can be duplicated, I'm sure that will be fixed soon-ish.
Now to wait for everyone to add webm support to their software, for the nextgen browser releases, and for more webm content to become available on the Internet. I don't think I'll be waiting long.
As you can tell I didn't do a real scientific analysis of webm and some will see this post as purely subjective... but I do strongly encourage everyone to give it a try for themselves and to report your findings in the comments. I'm guessing many will agree with me. :)