M U . K O . L I - video

Video codec comparison - 2002/03/09

intro

The aim of this little webpage is to make a roundup of a few video codecs on Windows (dunno about the rest). This is basicaly to help me decide what I will use to encode the TV programs I record and save on CD. The approximate duration of the programs I record are from 30 to 100 minutes. And I record these programs from the digital cable, through my Ati All In Wonder Radeon card (Composite input). My computer is an Athlon XP-1700+ with 256 MB of Crucial/Micron PC2100 memory in CAS2.

reason

As I said, I wanted to make this comparison to decide what format I'll use to encode my videos, since I use my computer as a VCR (digital in this case). I used to go for the DivX4 codec, but since DivX5 has just been published and the XviD codec is also now a decent alternative, I wanted to test in depth all these possibilities.

constraints

The program I record are usually debates or long news reports, so the particularities are slightly different from encoding a movie. But since I've tried many things, these general results probably apply to movie encoding too.

tests

I made 2 captures using the Ati Mutimedia Center in 704x576, interlaced using the Morgan MJPEG codec (until I found that the PicVideo one, provided with ShowShifter, has a slightly better quality). That's the process I generaly use to record/capture, because the computer is no fast enough to encode DivX/XviD in real-time. Also the Ati MMC doesn't provide the necessary configuration to use an audio codec for recording. So I usually record, and later compress the data to save it to a CD.

As I said, the maximum I usually record is 100 minutes. And the idea is to be able to save it on a 800 Mo. Since the only possibility to record is currenlty in AVI, there is no way to save the data in Mode 2 on the CD (see the work on the MCF to replace AVI in the future), so the legal size is 700 MB (overburning not taken in consideration). That means 700x1024x1024x8 bits = 5872025600 bits. So for 100 minutes (6000 seconds) it makes a general bitrate of 978671 bits/sec (or 978 kbps). As I want to be the videos as "compatible" as possible with other computers, I use MP3 for the audio codec. Especially the LameACM codec developped by... myself and the LAME dev team (you can find the latest alpha binary on Dmitry's page). I consider that 44100Hz/Stereo/128 kbps is a good choice. In this case it's in Constant BitRate because the Average BitRate is not yet implemented in the code so far. So that leaves 850kbps for the video. I actually used 1-pass 800 kbps for the following tests.

As the video is interlaced it will need to be deinterlaced first. I used VirtualDub for the tests, and so I simply used the built-in deinterlace filter (the smart deinterlace filter gives sharper results, but uses more CPU). I also add to crop the video because the card records everything including the parts of the video that you should never see (cut by your TV). Also as I wanted to acheive a quite good video quality at this bitrate, I had to resize the picture to a smaller part. So the data processing in VirtualDub goes like this :

VIDEO SOURCES -> crop -> deinterlace -> resize -> encode -> VIDEO OUT

The DivX5 comes with built-in crop, deinterlance and resize. It should make the encoding process a bit faster, since it allows (when all combined) you to use the Fast Recompress mode of VirtualDub.

sources

The 2 files I've used are short video files :

encoding speed

Since the 2 video sequences are quite short, the speed differences here are short and may vary when encoding longer parts.

source 1

DivX403:02
XviD02:58
DivX502:55
DivX5 +gmc03:16
DivX5 +qp03:25
DivX5 +gmc +qp03:56
DivX5 +bf03:17
DivX5 +gmc +qp +bf04:22
DivX5 +gmc +qp +bf +resize04:18
DivX5 +gmc +qp +bf +resize +crop04:20
DivX5 +gmc +qp +bf +resize +crop +deinterlace04:09
DivX5 +gmc +qp +bf +resize +crop +deinterlace (fast)03:28
DivX5 +gmc +qp +bf +resize +crop +deinterlace-basic (fast)03:31
DivX5 +gmc +qp +bf +resize +crop +IVTCdeinterlace-basic (fast) crash

source 2

DivX401:37
XviD01:34
DivX501:33
DivX5 +gmc01:43
DivX5 +qp01:48
DivX5 +gmc +qp02:00
DivX5 +bf01:45
DivX5 +gmc +qp +bf 02:18

conclusion

Without any options we clearly have DivX4 < XviD < DivX5. The additional options for the DivX all add more CPU usage. The more you have, the slower... It's also worth noting that using the Fast Recompress of VirtualDub can save a lot of CPU !

bitrate respect

As everything was encoded in 1-pass with a bitrate respect constraint, it's important to see how the codec respect what you asked them. I chose the 1-pass mode because that's the one I use (more convenient) and it also gives a "pure performance" aspect of the codec. I consider that if a codec is bad in 1-pass it's going to have to do more complicated work in 2-pass mode.

source 1

DivX410.532 KB750 kbps
XviD9.808 KB698 kbps
DivX510.510 KB749 kbps
DivX5 +gmc10.378 KB740 kbps
DivX5 +qp10.592 KB755 kbps
DivX5 +gmc +qp10.456 KB757 kbps
DivX5 +bf9.290 KB661 kbps
DivX5 +gmc +qp +bf9.312 KB668 kbps
DivX5 +gmc +qp +bf +resize9.118 KB654 kbps
DivX5 +gmc +qp +bf +resize +crop9.116 KB654 kbps
DivX5 +gmc +qp +bf +resize +crop +deinterlace9.734 KB693 kbps
DivX5 +gmc +qp +bf +resize +crop +deinterlace (fast)18.522 kB1329 kbps
DivX5 +gmc +qp +bf +resize +crop +deinterlace-basic (fast)18.188 KB1305 kbps

source 2

DivX46.230 KB844 kbps
XviD5.522 KB753 kbps
DivX56.184 KB838 kbps
DivX5 +gmc6.168 KB836 kbps
DivX5 +qp6.184 KB838 kbps
DivX5 +gmc +qp6.170 KB836 kbps
DivX5 +bf5.714 KB774 kbps
DivX5 +gmc +qp +bf5.726 KB776 kbps

conclusion

First of all, as you can see, the use of the deinterlacing produces MUCH greater files ! Actually it's because the deinterlaced images are not correct. And so they are very hard to compress. So you should consider doing the deinterlacing in VirtualDub instead. It's a bit sad because doing everything in the codec could boost the performance a lot.

The first produces lower bitrate than the requested bitrate, while the second produce bigger bitrate than requested. It's a bit sad too because that means you cannot rely on the codec for the bitrate. Even though the paramaters of all codec were to let it adjust the bitrate every 50 frames (2787 frames in the first source, 1466 in the second). Maybe it will produce more accurate bitrates in 2-pass mode.

The second source is bigger than what expected because half of it is made of football sequences with zooms on the players. So it's some of the hardest to compress images you'll find. Otherwise the codec produce smaller than expected files. It's nice when you want to put data on a CD. But it's bad when this space could be used for better quality images...

image quality

Of course all these numbers mean nothing if the quality of the resulting is shit. So I've selected a few things that you can notice between the codecs.

portrait - source 1

Here is a portrait (nice) on which you can see the differences of quality and the artifacts each of the codecs produce.

DivX4
DivX4 compressed
DivX5
DivX5 compressed
DivX5 + Quarter Pixel
DivX5 compressed + qp
XviD
XviD compressed
DivX5 + Quarter Pixel + GMC
DivX5 compressed + qp + GMC
DivX5 (Fast Recompress)
DivX5 Fast Recompressed

The first obvious thing is that there is a problem when using all the built-in parameters of DivX5 in Fast Recompress mode. Also XviD has too pixelisation and visible squares. It should rather use more space (as required) and improve the quality slightly. It is especially visible when you watch the videos in full-screen, which is what they're made for.

So the final is between DivX4, DivX5 and DivX5 + quarter pixel. The use of GMC doesn't seem to change the quality of the image, it just adds a better contrast. The Quarter Pixel seem to be a dithering of the image, which result is a kind of grain on the image. It might be usefull for complicated pictures (to counterfit the effect of blur in DivX), but in general the image looks worse than without. Maybe if it was a bit more subtle, it would be better. The difference between DivX4 and DivX5 is very very subtle.

footbal - source 2

As with decrypting video, the football images seem to be the hardest one to compress. Here is a good example of how bad the result is in this case :

DivX4
DivX4 compressed
DivX5
DivX5 compressed
DivX5 + Quarter Pixel
DivX5 compressed + qp
XviD
XviD compressed
DivX5 + Quarter Pixel + GMC
DivX5 compressed + qp + GMC
DivX5 + Bidirectional Frame
DivX5 Fast Recompressed

One again, it seems that the only acceptable formats are DivX4 and DivX5. XviD seems to be a good one, but the squares are still too obvious. Also, that's a good case where the Quarter Pixel does a really bad job. Also the B-Frame seem to have a better contrast than the simple DivX5. It's a very good achievement, since the resulting file is smaller !

artefacts

So DivX5 could be a good replacement for DivX4, since it's either faster or the quality is better. But there is a problem. The already famous "pink lines". Here is what you sometimes get when you decode the DivX5 file :

DivX4
DivX4 compressed
DivX5
DivX5 compressed

movements

I've noticed that when you use XviD between fast moving scenes there are big squares that disappear slowly (about 250ms). You get the same effect on the other formats, but much less noticeable. You can download the corresponding videos for each format by clicking on the image :

DivX5
DivX5 compressed
XviD
XviD compressed

conclusion

It seems that DivX5 is good at replacing DivX4 since it's faster with the same settings, which produce nearly the same pictures. It seem to be more an evolution rather than a revolution. Especially because you can play DivX5 files with the DivX4 codec as long as you don't use the new features when encoding (or maybe it's the DirectShow filter installed by DivX5 that is not deleted with the codec on uninstall). And it can even produce smaller files (instead of higher quality) when you specify a fixed bitrate... That's all good, but there is this "pink lines" bug which makes the codec unreliable so far. It sometimes crash too and some features are not functional. So wait for the next debugged version to forget about DivX4.

On the other hand I'm a bit disappointed by XviD. I heard a lot of praise about it. But it doesn't seem close to what DivX can do. Maybe it's not made for this kind of bitrate. But since it's in GPL I guess that all the new features of DivX will be in XviD soon (crop and resize are quite easy to code). They then need to concentrate on the picture quality.

//mukoli.free.fr/
steve . lhomme @ free . fr