 |
 |
 |
| |
|
|
 |
|
 |
 |
Select Interface Language:
|
|
|
|
|
 |
|
 |
|
VirtualDub vs. Avidemux - Comparison and Review - Full Text
Posted on Tuesday, January 30 @ 13:45:55 AST by Kurt |
|
|
|
In addition to writing open source software, I use a lot of it. Even just using the software is a form of contribution, which is why when I go looking for programs to fulfill a specific need, I will even take a hit on usability in order to be able to use open source. This is why I am going to start writing reviews for different open source software projects. For my debut, I am venturing into the realm of digital video processing.
This review will attempt to compare two excellent open source video editing products. Anyone who has transcoded a video in Windows has heard of, and probably used Avery Lee's ubiquitous Virtualdub. Less well known in the Windows circuit is the Avidemux project. This is because it comes to us as a port from Linux. It has recently come on my radar, and I've been giving it a go fot the last few weeks. Read on for my impressions of both products, and a comparison between them.
Introduction
Being a fan of watching videos on my PC, I've have also had to become a fan of transcoding them. Whether it's an AVI video I want to play for the whole family on a DVD player, or it's something I want to trim down to play on my Pocket PC, I've always had a need to move videos between formats. And let's not forget the ever popular video you download where whomever encoded it got the aspect ratio completely wonky.
I will say at the outset, that I am not a power video editor. My need for this software is pretty much that of transcoding between formats, with perhaps some cropping, deinterlacing, and other filters thrown in for good measure. Thus, some of VirtualDub's and Avidemux's (perhaps best) features are not being covered here.
VirtualDub
Overview:
Web site: http://www.virtualdub.org/
Author: Avery Lee
License: GPL v2
The incumbent, VirtualDub, is a well known and very mature application. It's purpose has been to act as a Microsoft Video for Windows (VfW) capture, editing, and transcoding tool. It is this very close association with this Windows technology that gives it both its power and its limitations. The advantage, is that it can use any installed VfW (video) or ACM (Audio Compression Manager) codec. In the past this would have given VirtualDub access to any codec on your computer.
Nowadays, DirectShow is Microsoft's flagship video technology (presumably because VfW lacked DRM and was too easy to use). Windows abandoned VfW, and it is starting to feel the effects of bit rot. One example of this is the use of B-frames. The AVI container doesn't support it natively, so codecs have to jump through hoops to get around this. Even though VfW is aging, many open source codec projects, Xvid as a notable example, are still available as VfW codecs. Some projects however, like x264 have officially abandoned support for VfW. There have been people step up to the plate for x264 to keep a VfW version of it going, but this is not part of the x264 project. The practical upshot is that VirtualDub is tied quite nicely to a native Windows technology and gleans advantages from that, but it is a deprecated technology that Microsoft would like everyone to just hurry up and forget about.
Features:
VirtualDub's design decision to lock into VfW can be considered a feature. VfW is technically a deprecated technology, but it is still widely used. Ironically, though, part of VfW's ongoing support can be attributed to the wide usage of VirtualDub. But it is nevertheless a useful feature for VirtualDub to be able to use any VfW & ACM codec installed on your computer. This creates a problem, though, in that the author has steadfastly refused to add support for anything that even smells like an AVI hack. If you want to take an AVI stream with packed B-frame VOPs and unpack them, then be prepared in VirtualDub to completely re-encode the video - VirtualDub won't even tell you whether or not the video stream containes packed VOPs. VBR support is similarly lacking. At least VirtualDub is aware of it. Prior to the 1.7.0 experimental release, all you could do to a video with VBR audio was completely uncompress the audio to a .WAV file in a separate operation, then reencode it along with the video. Now, as of the 1.7.0 experimental release, you are "merely" forced to reencode the audio.
If the author doesn't seem to like AVI hacks, he seems downright allergic to other container formats. VirtualDub will read MPEG-1 .mpg files, but its VfW-based system is completely locked into writing AVI files for output and only AVI. No MPEG containers, no MP4, no OGM. Zilch, nada, zippo. There are hacks forked off in various stages of abandonment that do have support for other containers. VirtualDubMod, for example, added some limited Matroska support, but it hasn't been updated since Virtualdub was in version 1.5.10 or so.
The one thing that somewhat mitigates VirtualDub's AVI lock-in is its ability to act as a frame server. That is, if you have a program that can read an AVI file as an input, then VirtualDub can pipe its output to that program without having to write out all of an actual AVI file. Sort of like piping the output of one program to the input of another on the command line. You set up VirtualDub with all the filters you want and put it in frame server mode. It will then save a tiny stub AVI file that you then use as the input for your target program. The target program, however, must be programmed to use Windows's own native VfW mechanism for its input. If the target program has its own AVI reader (like VLC, MPlayer, or Avidemux itself), then this doesn't work. You can use this to read an AVI file with VirtualDub, apply filters, and then pipe the output to a program like TMPGEnc to render it into MPEG-2. You can't use job control with frame serving, of course, so it's not nearly as nice as rendering directly, but at least you can use VirtualDub's filter system with some other encoders.
Which brings me to VirtualDub's filter system - in a word, it is simply excellent. As the de facto standard for Windows, Virtualdub filter plugins have the same position for video that Photoshop plugins have for images. There are dozens - maybe even hundreds. Commercial as well as free. I have yet to have wanted a filter for something and not been able to find one.
Lastly, one thing that I do with VirtualDub that Avidemux is completely lacking support for, is video capture. Virtualdub can use either VfW or WDM capture drivers to pull video in. Whatever else Avidemux can do, I will still be keeping Virtualdub around for this. The one thing I would love that VirtualDub doesn't do, is to have it frame-serve up captured video so other programs could use it too.
Performance:
Performance-wise Virtualdub is starting to feel the age of its design. Its author has added only very rudimentary support for multi-threading. All video decompression, filtering, and compression work is serialized into a single thread. The only real parallel processing that is possible is due to the audio encoding being in a separate thread. It's a good thing too, because with Virtualdub you will have to reencode the audio much more often, as it completely lacks the hackery that other software has to allow variable bitrate audio in AVI containers. My experience is that virtually all AVI video out there uses variable bitrate, so expect to reencode audio often in Virtualdub.
User Interface:
Here Virtualdub is the clear (and I think uncontested) winner. First of all, it has two-panels for video. One for input, one for output. You can see the results of your filters side-by-side with the original, playing in real-time (assuming your CPU is fast enough). It doesn't dumb down the interface with a wizard or even anything wizard-like, so don't expect it to hold your hand. For me this is not a drawback at all - I'd even a plus. Virtualdub supports all the standard Windows niceties - drag-and-drop (drop an AVI onto the program to open it), and standard Windows file requesters. Normally I wouldn't point this out, but Avidemux lacks even these standard niceties - but more on that below.
Stability:
VirtualDub is very mature and extremely stable. It's not perfect,
though, as my recent trial of Avidemux has shown. VirtualDub seems to
have a problem with Avidemux's AVI output. I have no problem opening
and playing an Avidemux-produced AVI in Windows Media Player, VLC, or
back in Avidemux, but VirtualDub will often crash trying to open it.
The crashes I noticed here have been the first crashes I've seen in
VirtualDub in a very long time. I'm pretty sure it is due to
non-standard or incorrect data that Avidemux is putting into the AVI
file - but that being said, it has always been my assertion that no
data, no matter how trashed, should cause a program to crash when you
tell it to load it.
Other than this, my experience is that VirtualDub is extremely stable.
Now, over to...
Avidemux
Overview:
Web Site: http://fixounet.free.fr/avidemux/
Author: Multiple
License: GPL v2
The challenger, Avidemux, is a newer entry to video editing on the Windows platform. It comes to us from Linux. Because no one has ever gotten around to making any sort of video codec standard stick in Linux, it uses the old faithful system that I call CramTheCodeForEveryCodecYouCanThinkOfAllInOneProgramTogether. This has its own set of advantages and disadvantages. The disadvantage being, that if the program doesn't support a codec you need, you're out of luck. Nothing you can do, except write support yourself and submit a patch. For those codecs it does have built in, this also means you can't update them independent of the program. If the Xvid project updates its codec with new features, you have to wait for Avidemux to incorporate a new build of the Xvid library. The advantage to this system is in not needing to worry about installing codecs to handle what Avidemux does support. Any long time Virtualdub user has inevitably had to search around for a hard-to-find ACM or VfW codec for that video you want to transcode.
Features:
Avidemux comes arrayed with an impressive list of built-in codecs it supports. For encoding video: H263, MJPEG, MPEG4 part 2/Xvid, Mpeg 4 part 10/x264, MPEG 1 (VCD) & 2 (SVCD/DVD), HuffYUV, FFV1, and raw (uncompressed). The audio list is similarly impressive: MPEG-1 layers 2 & 3 (MP2 & MP3), AAC, A52/AC3, and Vorbis. As noted above, these are all built into the program itself. No separate codec installations needed. Where Avidemux really shines is in its support for extra containers. In addition to AVI, it supports Ogg Media (OGM), MP4 (MPEG4 part 14), MPEG Transport Stream/MPEG-TS, and MPEG Program Stream/MPEG-PS (including VOB) for input and output. For input, it will try to open Matroska, but more often than not fails (it also takes huge chunk of memory while it tries too, so don't try this at home kids unless you have a well endowed system). Besides these containers, more are coming. This sort of codec and container support comes close to being the Holy Grail of trancoding - which I describe as "input from any container & any codec, filter, then output to any container & any codec". Being that I've alternatively wanted to take a DVD and turn it into an AVI one day, then with another video the next day do the opposite, this is an exciting prospect. The One Ring of transcoders. It's close, but without proper OGG (not the Ogg Media OGM hack done before .OGG supported video) and Matroska, and without work on its stability (more on this below), it's not quite there yet.
Avidemux, in addition to it's array of containers, has no aversion to working with hacks of AVI. If you open a video with packed B-frames, it will happily detect this offer to unpack it for you. No reencoding necesary. It will also happily deal with variable bitrate audio with AVI. When opening a video with VBR audio, Avidemux will offer to build a time map for you - after this, further processing can occur without further difficulty.
While close to being the holy grail of transcoders, don't expect to be frame-serving or doing video capture. This just isn't in the picture for Avidemux. Both of these require an intimacy with the operating system that just isn't likely for a project ported from Linux.
The filters in Avidemux are also excellent. The list is extremely inclusive - the only thing I could ask for is a filter API so that filters can be added later. All Avidemux filters are built-in. If they really wanted to be nice, they could support the Virtualdub filter API - access to the store of Virtualdub filters that are already made could only enhance Avidemux. Not just in Windows, either - there would be many open source VirtualDub filters that would work in Linux with little more than a recompile.
While the filters are great and the prospect of having one program to encode them all is something I find absoultely titillating, some features that make life easier are missing. For example, there's no way to save MPEG output to separate non-muxed video and audio streams. You have to first export the audio separately, then select a video-only container. The big features are all here, it's the small ones that sometimes are absent.
Performance:
I will note straight away that I have not tested Avidemux on a strictly single-processor computer. My main workstation is an SMP dual Athlon machine.
I was actually quite shocked to discover how good Avidemux's performance was. I expected to take a performance hit considering it's a Linux application ported to Windows. The fact it is ported might make for a sub-par UI (more on that later), but it certainly has not affected its speed. This stems partially from the fact that Avidemux has better multi-threading than VirtualDub. I don't know how the thread structure is set up, but you can set the number of threads in the preferences. I suspect this setting for the number of threads is used only for certain encoders. The Xvid project, for example, recently added support for slicing up encoding among different threads. The threading support is better than can be explained by this alone, however. I found a VfW version of XViD with this multi-thread support, and even with this in VirtualDub, Avidemux still uses more of my PC's dual CPUs than VirtualDub. I suspect that video decompression, filtering, and compression are all in their own threads.
And even after taking into account Avidemux's more efficient use of multiple CPUs, it still is apparent that at least with certain codecs Avidemux does more with its CPU time than Virtualdub does. Considering the wide assortment of code from different projects that is mixed together in Avidemux, and the maturity of Virtualdub, this surprised me greatly. More on this in the cook-off section.
User Interface:
Get ready, because this is going to be long winded. The user interface is the one area in Avidemux that needs help. First off, I will say right here that I don't give any leeway for the fact that it's a ported program using a non-native widget system. My opinion is, if you're going to port something to Windows, then do it right.
Avidemux's UI problems are many and varied. First of all, design issues. Its single preview pane is (forgive the pun) a pain. There's only one spot for video preview, and if you want a second to compare input with output you have to have a separate window. The extra preview window can't be closed by clicking on the 'X' in the title bar - you have to find the setting that turned on that window in the first place and turn it off. You can resize the preview windows only within a small number of presets (no support for arbitrary preview window sizes) and you can't view them with a different aspect ratio. There is no right-click context menu for the preview window either, which is something I got used to having with Virtualdub.
The preview pane also doesn't support native Windows rendoring methods like DirectX, and the ony "faster" method it does support (SDL), doesn't work. When you press play with SDL output, the display of the video jumps up off the Avidemux window to the left corner of your screen. The one preview window has no whitespace around it, making it seem to but right up against window controls. There is absolutely no preview capabaility at all while encoding is in progress. Just a plain progress bar. This means when your FPS drops into the toilet during processing, you can't see the scene that is causing the issue - which makes it harder to adjust future projects to compensate.
Other UI issues actually qualify for bug status. One being that while it is possible to have a non-integral quantizer for Xvid, and while the UI seems to recognize this and for this codec let you set it to a non-integral value, when you go back to the codec configuration you see that the value has snapped to an integer. My preference is 3.5, and I can't use that in Avidemux. And while probably not a bug, the lack of saving your codec settings between sessions is particularly frustrating. I do a lot with Xvid, and I'm fussy about how I like it configured. It would be nice if it remembered settings between sessions.
Some of Avidemux's interface problems stem from the fact that it is a GTK application. As such, some of its UI deficiencies are due to the continuing overall low quality of the GTK port to Windows. The GTK file requester dialog, even in Linux, can only be described as unfortunate. It reminds me of the old Windows 3.1 requester. Functional - barely. No file drag and drop between the requester and Windows Explorer, no right-click access to explorer functionality, and the propensity it has for forcing you to click on "Browse for other folders" if you want to save somewhere else other than where it thinks you want to is downright annoying. Avidemux's file extension support is poor (mostly absent). No default extensions when saving - you have to remember to type in the extension every time. I've had to rename videos I've forgotten to do this with more than once. When opening it lacks filters for some containers it supports (like *.ogm).
The main window is servicable enough for a transcoder. You can immediately see what your settings are for input and output. Even there, though, certain elements are confusing. For example, when you open an AVI video with packed frames, you are asked if you want to unpack. If you click yes, then your output file container is automatically set to "AVI, unp. VOP". If this is set, then anything you specify for output codec and filters is quietly ignored without further warning. If "AVI, unp. VOP" infers a video stream copy, then this is all you should be able to do. Other options should be greyed out.
So, while the UI looks clean (though the lack of spacing between controls and the preview pane makes it look a little "slapped together"), it is rife with inconsistencies and things you just have to "put up with".
Stability:
While the UI is annoying, it is something I can
work with. The stability issues are another thing. If you are
transcoding to AVI, expect the program to be pretty stable. When you
start encoding into other containers, the "assertion" violations and subsequent crashes start
becoming common. Some are readily reproducable. For example, if you
are encoding MPEG output and you try to overwrite a file - CRASH, every
time. At other times, you can't tell in advance. Sometimes it works, sometimes it doesn't. This means ou have to really tiptoe around the UI. This is
particularly frustrating when you have set up a complex filter chain -
one where you've spend half an hour with a calculator working out the
cropping pixels and aspect ratio conversion, only to have the program
crash when saving. The rule here is to save your project often.
The Cook Off
Ok, now for the good part - a transcoding cook-off between VirtualDub and Avidemux.
For my test I am transcoding a video to make it easier to watch on my Pocket PC. This particular video doesn't have square pixels. It's a 16:9 anamorphic aspect ratio with actual resolution of 720x480. I want 320x240 in the end, with square pixels and no letterbox. To accomplish this, I am cropping to 540x480 and then resizing down to 320x240. I am cropping first to save time - it's easier to calculate the reduction if you resize to the correct aspect ratio first, crop, then resize again to the right size, but this takes more work and processing power. You save more time in the end if you spend a few moments with a calculator to figure out the cropping first, then resize down in one shot. I subscribe to the rule of thumb that suggests bilinear for shrinking.
Virtualdub, version 1.7.0 (experimental)
Filters: Null transform first, cropping to 540x480, then the built-in resize. I use the fastest bilinear (interpolation).
Codec: I installed the latest XViD binaries I can find (1.2-127) to give SMP support right in the VfW codec (this is the only way VirtualDub can even stay in the ballpark performance-wise). I set the number of threads to two (for my dual CPUs). Single pass, target quantizer set to 3.0 (because I can't use my usual 3.5 in Avidemux and I want both programs the same). Adaptive quantization and B-VOPs are turned on. B-VOP quantizer ratio & offset are left at what "load defaults" sets them to because Avidemux doesn't expose those settings. Motion search is ultra-high, VHQ is mode decision. VHQ for B-frames is turned on, as is chroma motion and turbo. Global Motion Compensation & QuarterPel are both turned off.
Audio: Copy (in order to be a fair comparison, I found a source video without VBR)
General: Highest thread priority, no video preview during processing.
Avidemux: version 2.3.0+
Filters: Cropping first for 540x480, then the MPlayer Resize filter set to "Bilinear".
Codec: Everything the same as in VirtualDub where possible. Xvid single pass - quantizer set to 3. Turbo Mode and Packed bitstream are turned on. Chroma Motion, 4MV, and HQ AC are also turned on. B-Frames are set to a max of two, and VHQ for them is turned on. The minumum quantizer for all frame types is set to 1, since that is the VfW codec defaulted to.
Audio: Copy
General: Number of threads set to 2. Since there is nowhere to set the priority, out of a sense of fairness I used Task Manager to up the priority of the whole process to highest.
Results:
Virtualdub: 58% CPU usage average, 1:05:39 total time (3939 seconds, 42.66fps average), 439784kb output size
Avidemux: 62% CPU usage average, 53:48* total time (3228 seconds, 52.06fps average), 435091kb output size
Analysis:
I really gave VirtualDub every break I could - I found a multi-threading VfW codec so it could compete, and chose a (rare) source video that had constant bitrate audio so it didn't have to reencode it. Despite this, it still clocked in 20% slower than Avidemux.
There is more at work here than Avidemux's better use of dual CPUs. If VirtualDub has as much CPU utilization, it still would have clocked in at 1:01:24. Avidemux was both more efficient (more work per clock cycle) and better able to use multiple processors. Quite the combination. The file size is a little puzzling. The Xvid settings were as close I could make them, and both were set to interleave audio/video every frame. Not sure why Avidemux was smaller - perhaps some esoteric setting inside the codec itself. The size difference, percentage wise, isn't big enough to be a real issue though.
Conclusion
At some point, I will be retiring VirtualDub for anything except video capture. However, today is not that day. Avidemux's wide container support is something that excites me greatly. It's excellent performance was icing on that cake. I would be willing to convert, even with the poor state of its UI, except for the stability issues. These ended up being the killer in the end.
That being said, I still use (and plan on continuing to do so) Avidemux. It has become my standard program to use when transcoding ripped DVD video to AVI.
I had also hoped to use Avidemux to act as my DVD authoring solution - taking downloaded and home-recorded MP4 from my pocket PC camera and creating DVDs. My current solution is using Virtualdub set up as a frame server with TMPGEnc doing the mpeg-2 encoding. I would like nothing more than to eliminate frame serving, but Avidemux just isn't stable enough when working with MPEG output to do that yet.
So, while Avidemux has earned a spot in my permanent tool list, it hasn't displaced Virtualdub yet. However, unless Virtualdub's author takes a long hard look at his insistance on keeping it tied only to VfW and AVI, it's only a matter of time until Avidemux does displace it.
|
|
 |
|
 |
| |
|
|
|
| |
|
|
|
|
|
|
| Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name. |
|
|
|
|
|
|
|
|
| "VirtualDub vs. Avidemux - Comparison and Review" | Login/Create an Account | 0 comments |
|
| | The comments are owned by the poster. We aren't responsible for their content. |
|
|
|
|
|
|
|
|
|
No Comments Allowed for Anonymous, please register |
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
| Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name. |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| There isn't a Biggest Story for Today, yet. |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| Friday, January 04 | | · | Back From Basic Training |
| Thursday, August 23 | | · | Preparing for Basic Training in the Canadian Forces - UPDATED |
| Friday, July 13 | | · | Selling domain names |
| Friday, June 08 | | · | Fair Winds and Following Seas |
| Thursday, April 12 | | · | Site Back - Welcome to my Japanese Friends |
| Wednesday, April 04 | | · | Download Site Awards - An Author's Quest for Glory |
| Sunday, April 01 | | · | Whoops, I Did It Again - SelfImage 1.2.1 |
| Saturday, March 31 | | · | Thanks a million |
| Friday, March 30 | | · | SelfImage 1.2.0 - Better Linux Support |
| Thursday, March 29 | | · | Welcome to my home |
| Monday, February 12 | | · | Whoops - SelfImage 1.1.3 to the Rescue |
| Wednesday, February 07 | | · | SelfImage version 1.1.2 (built 65) Released |
| Friday, February 02 | | · | An Open Letter to Site Hackers |
| Tuesday, January 30 | | · | VirtualDub vs. Avidemux - Comparison and Review |
| · | On Hold |
| Saturday, December 16 | | · | New Login CAPTCHA |
| Wednesday, November 08 | | · | Warship Day Sail Photo Album |
| Friday, November 03 | | · | NOAB - Naval Officer Assessment Board |
| Wednesday, October 25 | | · | Comments Working Again |
| · | Career Change |
| Thursday, April 20 | | · | GPGee 1.3.1 Released |
| Tuesday, March 28 | | · | C++ Builder 2006 |
| Friday, March 03 | | · | New Web Server Hardware - UPDATED |
| Tuesday, January 17 | | · | GPL v3 |
| Friday, January 13 | | · | GPGee 1.3.0 is out - SmartCard support |
| Tuesday, December 27 | | · | SelfImage 1.1.1 Released |
| Monday, December 12 | | · | Bug in GPGee 1.2.2 - version 1.2.3 released |
| · | 100,000 hits! |
| Sunday, December 11 | | · | GPGee version 1.2.2 released! |
| Saturday, December 10 | | · | SelfImage 1.1 Released |
Older News Items
|
|
|
|
|
