|First off, a quick introduction. What is a codec and what is an encoder. If you capture footage directly and store each frame as "raw" or uncompressed, the disk space needed is extreme. The same goes for the audio. Now everyone is familiar with MP3 (Mpeg Layer 3 Audio). MP3 is a codec designed for audio compression, and as such you can compress a 50mb wave file down to about 5mb mp3 with little or no apparent quality loss. The same goes for Video. The Encoder is the program that does the processing using the codec. Some encoders are more efficient than others. This test was designed to work out which codec produces the smallest filesize while still retaining image quality, and which encoder was faster, while once again still retaining image quality.|
|CPU||Intel Celeron FC-PGA 900mhz, overclocked to 1.134 ghz|
|Motherboard||MSI BX-Master, Intel 440BX chipset|
|RAM||384mb DIMM, @ 126mhz|
|Capture Card||Pinnacle Studio PCTV Rave|
|Capture Settings||PAL, 384 x 288, 25fps, 44.1khz 16bit Stereo Audio. All original footage using Huffyuv codec|
|Input Source||Free To Air Broadcast, Analogue PAL, using Tuner on Capture card|
|Operating System||Windows 98SE version 4.10.2222|
|Virtual Dub||version 1.4.10 Build 13870|
|Tmpgenc||version 220.127.116.11 Core 1.90.138|
|Tmpgenc Plus||version 18.104.22.168 Core 1.90.138|
|Cinema Craft||version 22.214.171.124|
|Div-X version 5.0.0 build 413||Div-X version 5.0.2 build 487||Div-X version 5.0.2 Pro build 481|
|Div-X version 4.01 build 195||Mpeg 1 (constant bitrate CBR)||Mpeg 2 (constant bitrate CBR)|
|Original Video Footage : duration 48 minutes 23 seconds.
Description : Testing the difference between two versions of Div-X
|Video Setting||Audio Setting
|632,096,768||Virtual dub||Divx 5.0.2||384 x 288||1-pass Quality Based 93%||128|
|628,238,336||Virtual dub||Divx 5.0.0||384 x 288||1-pass Quality Based 93%||128|
|Div-X 5.0.2 results in a larger filesize with no apparent video quality improvement, or encoding speed.|
|Original Video Footage : Duration 14:25 minutes. 21,626 Frames.
Compressed with DivX 5.0.0 on 1 Pass Quality Based 93% with MP3 Audio at 128kbit 44khz Stereo.
Description: Here you can see a single frame from a tv show called Atoms Alive. You can clearly see the black lines top and bottom. Scroll to the right to see the frame size reduction versus file size reduction. The white colour is not part of the frame, I have just left the white on each picture to keep them aligned in the table.
Frame size 384 x 288
File Size 103,808 KB
Frame size 384 x 240
File Size 99,616 KB
Frame size 384 x 218
File Size 98,846 KB
|It's quite evident that reducing the frame size has a direct result on reducing file size when encoding with Div-X.|
|There is one thing that has to be considered when using version 5.0.0. In version 5.0.2 they fixed an issue where encoding content with resolutions not divisible by 16 would cause purple and pink artifacts to appear in the output file. You can still encode content that has resolutions divisible by 4 or 8, however they strongly recommend encoding only content with resolutions divisible by 16, as the 4 and 8 dimensions will not encode as efficiently. *However* If you encode some footage with version 5.0.0 and crop outside the divisible by 16 frame size, and you see these artifacts, when you play this same file with version 5.0.2 installed, these artifacts are not always visible. So that would indicate to me it's more of a decoding issue rather than an encoding one.|
|Original Video Footage : Duration 29:08.960 minutes. 43,724 Frames.
Description: The reason for this test, is most shows broadcast now are not fullscreen, they have black bars top / bottom when viewed on the PC screen, as the pc screen uses standard 4:3 aspect ratio. So does cropping out these black bars influence the filesize?.
|Video Setting||Audio Setting
|228,675,584||Virtual dub||Divx 5.0.2||384 x 248||1-pass Quality Based 93%||128||384 x 288|
|223,666,176||Virtual dub||Divx 5.0.0||384 x 248||1-pass Quality Based 93%||128||384 x 288|
|283,498,500||Tmpgenc||Mpeg 1||384 x 248||1,150 kbit/s||128||384 x 288|
|Once again Div-x 5.0.0 produces a smaller filesize.|
|When cropping with mpeg there is NO filesize benefit.|
|If you compare the above filesizes to the filesizes in TEST 4, you can see the savings gained by cropping with Div-X|
|Original Video Footage : Duration 29:08.960 minutes. 43,724 Frames.
Description: Which encoder was faster, and which one produced the smallest filesize
|Video Setting||Audio Setting
|230,418,432||Virtual dub||Divx 5.0.2||384 x 288||1-pass Quality Based 93%||128||40|
|227,444,736||Virtual dub||Divx 5.0.0||384 x 288||1-pass Quality Based 93%||128||40|
|283,498,500||Tmpgenc||Mpeg 1||384 x 288||1,150 kbit/s||128||61|
|283,498,500||Tmpgenc Plus||Mpeg 1||384 x 288||1,150 kbit/s||128||61|
|289,312,772||Cinema Craft||Mpeg 1||384 x 288||1,150 kbit/s||128||45|
|372,252,676||Tmpgenc||Mpeg 1||384 x 288||1,550 kbit/s||128||61|
|372,252,676||Tmpgenc Plus||Mpeg 1||384 x 288||1,550 kbit/s||128||61|
|379,815,940||Cinema Craft||Mpeg 1||384 x 288||1,550 kbit/s||128||45|
|472,113,156||Tmpgenc||Mpeg 1||384 x 288||2,000 kbit/s||128||61|
|472,113,156||Tmpgenc Plus||Mpeg 1||384 x 288||2,000 kbit/s||128||61|
|481,599,492||Cinema Craft||Mpeg 1||384 x 288||2,000 kbit/s||128||45|
|284,327,940||Tmpgenc||Mpeg 2||384 x 288||1,150 kbit/s||128||61|
|284,327,940||Tmpgenc Plus||Mpeg 2||384 x 288||1,150 kbit/s||128||61|
|290,258,948||Cinema Craft||Mpeg 2||384 x 288||1,150 kbit/s||128||45|
|373,340,164||Tmpgenc||Mpeg 2||384 x 288||1,550 kbit/s||128||61|
|373,340,164||Tmpgenc Plus||Mpeg 2||384 x 288||1,550 kbit/s||128||61|
|381,022,212||Cinema Craft||Mpeg 2||384 x 288||1,550 kbit/s||128||45|
|473,481,220||Tmpgenc||Mpeg 2||384 x 288||2,000 kbit/s||128||61|
|473,481,220||Tmpgenc Plus||Mpeg 2||384 x 288||2,000 kbit/s||128||61|
|483,153,924||Cinema Craft||Mpeg 2||384 x 288||2,000 kbit/s||128||45|
|304,885,560||Tmpgenc||VCD Mpeg 1||352 x 288||1,150 kbit/s||224||62|
|304,885,560||Tmpgenc Plus||VCD Mpeg 1||352 x 288||1,150 kbit/s||224||62|
|(not supported)||Cinema Craft||VCD Mpeg 1||352 x 288||1,150 kbit/s||128||n/a|
|609,227,304||Tmpgenc||SVCD Mpeg 2||480 x 576||2,520 kbit/s||224||102|
|609,227,304||Tmpgenc Plus||SVCD Mpeg 2||480 x 576||2,520 kbit/s||224||102|
|(not supported)||Cinema Craft||SVCD Mpeg 2||480 x 576||2,520 kbit/s||128||n/a|
|Once again Div-x 5.0.0 produces a smaller filesize. However the 2000 kbit/s mpeg's produced a slightly better quality picture than Divx. But the additional filesize versus this small quality improvement, in my humble opinion can't be justified.|
|For encoding speed, Div-X once again wins. Cinema Craft was considerably faster than Tmpgenc, but the files created were larger.|
|As a comparison test, I also produced a VCD and SVCD file using the accepted standard mpeg settings.|
|I had some requests for more extensive Div-X testing, so what I have done is a few more comparison tests
between CBR (Constant Bit Rate) Div-X encoding and the VBR (Variable Bit Rate, which is called Quality Based in the
Also I've compared version 5.0.2 PRO to version 5.0.0 and version 4.01.
For these tests, I have used a longer duration of footage (just under 2 hours). Also the footage I used was displayed in wide screen format and as such had black lines top/bottom when displayed on a normal 4:3 aspect screen. In the previous tests, Cropping these black lines produces quite a filesize saving. So all tests were cropped. I have done 2 tests uncropped to demonstrate just how much larger the files created are and how much longer it took to encode them.
|Original Video Footage : Duration 1 hour 54 minutes 8 seconds: 171,202 Frames.
Description: Testing different settings within the codecs and comparing each version of the codec. Which setting / version, produces the smallest filesize, and/or the shortest encoding time.
|571,021,312||Virtual dub||Divx 5.0.2 Pro||384 x 240||384 x 288||1-pass Quality Based 93%||1:48||26.67 fps|
|726,884,352||Virtual dub||Divx 5.0.2 Pro||384 x 240||384 x 288||1-pass Quality Based 95%||1:50||25.94 fps|
|732,532,736||Virtual dub||Divx 5.0.2 Pro||384 x 240||384 x 288||1-pass CBR, 780 kbit/s||1:46||26.92 fps|
|1,042,444,288||Virtual dub||Divx 5.0.2 Pro||384 x 240||384 x 288||1-pass CBR, 1,150 kbit/s||1:48||26.67 fps|
|1,301,649,408||Virtual dub||Divx 5.0.2 Pro||384 x 240||384 x 288||1-pass CBR, 1,550 kbit/s||1:50||25.94 fps|
|1,360,850,944||Virtual dub||Divx 5.0.2 Pro||384 x 288||384 x 288||1-pass CBR, 1,550 kbit/s||1:57||24.05 fps|
|562,274,304||Virtual dub||Divx 5.0.0||384 x 240||384 x 288||1-pass Quality Based 93%||1:44||27.44 fps|
|717,260,800||Virtual dub||Divx 5.0.0||384 x 240||384 x 288||1-pass Quality Based 95%||1:44||27.44 fps|
|732,506,112||Virtual dub||Divx 5.0.0||384 x 240||384 x 288||1-pass CBR, 780 kbit/s||1:44||27.44 fps|
|1,041,766,400||Virtual dub||Divx 5.0.0||384 x 240||384 x 288||1-pass CBR, 1,150 kbit/s||1:46||26.92 fps|
|1,296,715,776||Virtual dub||Divx 5.0.0||384 x 240||384 x 288||1-pass CBR, 1,550 kbit/s||1:47||26.67 fps|
|1,357,254,656||Virtual dub||Divx 5.0.0||384 x 288||384 x 288||1-pass CBR, 1,550 kbit/s||1:59||23.98 fps|
|865,067,008||Virtual dub||Divx 4.01||384 x 240||384 x 288||1-pass Quality Based 93% Slowest||2:04||23.01 fps|
|1,550,585,856||Virtual dub||Divx 4.01||384 x 240||384 x 288||1-pass Quality Based 93% Fastest||1:42||27.97 fps|
|1,000,146,944||Virtual dub||Divx 4.01||384 x 240||384 x 288||1-pass Quality Based 95% Slowest||2:07||22.47 fps|
|1,750,716,416||Virtual dub||Divx 4.01||384 x 240||384 x 288||1-pass Quality Based 95% Fastest||1:42||27.97 fps|
|733,603,840||Virtual dub||Divx 4.01||384 x 240||384 x 288||1-pass CBR 780 kbit/s Slowest||2:00||23.79 fps|
|1,041,422,336||Virtual dub||Divx 4.01||384 x 240||384 x 288||1-pass CBR 1,150 kbit/s Slowest||2:05||22.83 fps|
|1,291,681,792||Virtual dub||Divx 4.01||384 x 240||384 x 288||1-pass CBR 1,550 kbit/s Slowest||1:55||24.81 fps|
|1,394,149,376||Virtual dub||Divx 4.01||384 x 240||384 x 288||1-pass CBR 1,550 kbit/s Fastest||1:40||28.53 fps|
|1,353,811,968||Virtual dub||Divx 4.01||384 x 288||384 x 288||1-pass CBR 1,550 kbit/s Slowest||2:15||21.14 fps|
|1,054,517,252||TMPGenc||Mpeg 1||384 x 240||384 x 288||1,150kbit/s||3:29||13.65 fps|
|Quality Based Encoding: As you can see, version 5.0.0 produces considerably smaller files. Encoding times version 5.0.0 wins once again. Version 4.01 with it's Fastest option is slightly faster, however taking into consideration the file sizes and the picture quality loss, it's not really a viable option.|
|Constant Bit Rate Encoding: Filesize wise, all are about the same. Encoding times version 5.0.0 once again pulls slightly ahead.|
|Un Cropped Test: Version 4.01 is slightly ahead with filesize, but encoding times version 5.0.0 still has the advantage. (The uncropped tests are the ones with the framesize in bold).|
|Div-X CBR versus Mpeg1: All versions of Div-X are only slightly ahead for filesize, but what lets mpeg down is the arduous encoding times. Cropping all versions of Div-X not only results in a considerable filesize saving, but also reduces encoding times. No advantages are gained with cropping a MPEG.|
|Notes: In the configuration of Div-X 4.01 there are two options for Performance/Quality; Slowest and Fastest. To save myself some time, I didn't do a slowest versus fastest test for every divx 4.01 CBR. Instead I only did a fastest versus slowest for one of the CBR's in this test. You can see that even though Fastest is quite fast, the filesize produced is considerably larger. So all round, choosing Fastest is not a viable option if Quality and filesize are important.|
|Notes: All Encoding times have been rounded to the nearest minute|
|To see some frame image comparisons from TEST 1 through 5 GOTO THIS PAGE *Warning* this page is 3MB in size.|
|I found no benefit in using the Plus version of Tmpgenc.|
|I found no benefit in using Div-X version 4.01 instead of version 5.0.0|
|I found no benefit in using Div-X version 5.0.2 instead of version 5.0.0 (other than the remote possibility to prevent purple artifacts while viewing non 16x frame size files).|
|I found only one benefit in using Div-X version 5.0.2 PRO instead of version 5.0.0 (other than the above point). When comparing frames 5.0.2 PRO had slightly more detail than version 5.0.0|
|Version 5.0.2 of divx not only produces a larger filesize, but is also slower to navigate when using the progress bar. (this is when viewing the created avi). I might explain this a little better with version 5.0.0, when viewing a avi, and you jump quickly ahead (say by 40mins), there will be a slight delay and then the footage will be displayed (a/v sync is fine). However with version 5.0.2 (and the PRO) when you jump ahead (say by 40mins), the audio starts playing instantly, however it still takes the same time for the video to appear and when it does appear, it runs at upto 100fps until a/v sync is achieved. This looks totally disgusting imho. I certainly prefer the slight wait, rather than seeing the footage run at 4 times it's encoded speed for a second or two in it's attempt to catch upto the audio signal. This is evident in all test files, in any viewer program I use.|
|All versions of Div-X do a better job when the frame is complex (has lots of detail).|
|Divx has the most problems on gradient colours, or smooth single colour large areas.|
|Div-X version 4.01 (when using Slowest setting) Did a very good job, quality wise. However it's encoding times and filesize when using Quality Based encoding have certainly been improved with version 5.0.0.|
|All Divx files were viewable with version 5.0.2. However all files created with version 5.0.2 were NOT viewable with version 5.0.0.|
|Divx requires more CPU usage than Mpeg's to view.|
|There is NO benefit in cropping or resizing (up) Mpeg's.|
|Cinema Craft is certainly faster than Tmpgenc for encoding, and has a few options not available in tmpgenc but mpegs created were larger in every test and the created files were lower quality than those created by Tmpgenc.|
|Windows Media Player has some problems playing Divx avi's *if* you switch back and forth. This could be a WMP version related problem that may have been fixed in versions later than the one I'm using.|
|Windows Media Player has problems playing back Mpeg 2 files. As above point this may be version related, but I found viewing a mpeg2 WMP would sometimes display it out of aspect, but on the next load it wound be fine.?.|
|Interview's WinDVD player had no problems playing back any files.|
|With the release of version 5.0.5 of Div-X, it was time to test it against version 5.0.0 (which
has already proved superior from the above tests.) Is 5.0.5 better or worse.
Now with version 5.0.5 it makes it a little more difficult to do a direct comparison because they have made some large changes to how Div-X operates. For example they are using Profiles now. This allows Div-X to conform to similar standards as used by MPEG. The reason for this is simple. Div-X want hardware decoding support, but in order to gain that, it seems some encoding methods have to change. There are a few products out now that can decode div-X in hardware, However I can't test the functionality of this versus the set profiles, or custom encoding methods. Quality Based encoding (the preferred method by me) has now been removed completely from the Div-X setup screen. So if you wish to still use QB encoding, you have to DISABLE all profiles, then it magically appears, and you get a warning about non-conformance. It's a shame Div-X have to hide their best feature. Progress I suppose..
Ok, the other thing that is making a direct comparison difficult is the Constant Bitrate Tests. Version 5.0.5 have a new method of using CBR (with the profiles). You now set which bitrate you want, however depending on which profile you select, the maximum bitrate level changes. This means you can set a bitrate of 1,500kbps, and find out the file is MASSIVE. This is due to there being a maximum bitrate of 4000kbps. Now if you ask me this sounds more like quality based encoding, where a frame that requires more data is given it (upto the maximum bitrate). So why then remove QB from the profiles?.. I dunno. Anyways. What i have done is disabled the profiles, set the bitrate AND maximum bitrate to my selection. This imho is more of the traditional CBR encoding method. Some of you may find this unacceptable as a comparison, as the frame image quality improves considerably if the maximum bitrate is higher, except the filesize(which is also considered as very important by me and my tests) increases considerably aswell. I will do one test using the Profile, as a comparison.
|Original Video Footage : Duration 1 hour : 90,000 Frames.
Description: Two main tests for this. A) Filesize, B) Frame Image Quality. I didn't worry with actual encoding times as previous divx versus divx tests produced very similar times. Footage was via the onboard tuner, using rooftop aerial and RG-59 cable. Captured in AVI_IO using Huffyuv, YUY2 frame image format with VFW version 4.0.0 drivers.
|Video Setting||Additional Information|
|1,304,645,632||Virtual dub||Divx 5.0.0||768 x 576||1-pass Quality Based 4|
|704,092,160||Virtual dub||Divx 5.0.0||768 x 576||1-pass Constant Bitrate; 1,500 kbps|
|677,271,552||Virtual dub||Divx 5.0.0||768 x 576||2-pass Constant Bitrate; 1,500 kbps|
|1,086,468,096||Virtual dub||Divx 5.0.5||768 x 576||1-pass Quality Based 4|
|617,799,680||Virtual dub||Divx 5.0.5||768 x 576||1-pass Constant Bitrate; 1,500 kbps|
|662,312,960||Virtual dub||Divx 5.0.5||768 x 576||2-pass Constant Bitrate; 1,500 kbps|
|675,663,872||Virtual dub||Divx 5.0.5||768 x 576||1-pass Constant Bitrate; 1,500 kbps||Using High Definition Profile|
|677,222,400||Virtual dub||Divx 5.0.5||768 x 576||2-pass Constant Bitrate; 1,500 kbps||Using High Definition Profile|
|475,092,992||Virtual dub||Divx 5.0.0||384 x 288||1-pass Quality Based 4||Using Bi-Cubic Resize filter a=-1.00|
|413,532,160||Virtual dub||Divx 5.0.5||384 x 288||1-pass Quality Based 4||Using Bi-Cubic Resize filter a=-1.00|
|659,456,000||Virtual dub||Divx 5.0.0||384 x 288||1-pass Constant Bitrate 1,500 kbps||Using Bi-Cubic Resize filter a=-1.00|
|670,539,776||Virtual dub||Divx 5.0.5||384 x 288||1-pass Constant Bitrate 1,500 kbps||Using Bi-Cubic Resize filter a=-1.00|
|685,047,812||TMPGENC||MPEG-1||768 x 576||Constant Bitrate; 1,500 kbps|
|687,081,476||TMPGENC||MPEG-2||720 x 576||Constant Bitrate; 1,500 kbps||I had to reduce the framesize
due to TMPGENC complaining
about 768 being too high.
|To see some frame image comparisons from TEST 6 GOTO THIS PAGE.|
|Quality Based Encoding: Well I must say that I'm surprised to see that version 5.0.5 produced smaller files. However the slight loss in image quality is also a concern, so I think I'd still have to choose version 5.0.0.|
|Constant Bitrate Encoding:1 PASS Again version 5.0.5 came through as producing the smaller file,
and this time there was not that much difference in frame quality, so for the filesize saving versus the slight
reduction in quality, version 5.0.5 wins.
2 PASS This was certainly alot closer in filesize with a slight edge to version 5.0.5. Image quality though still goes to version 5.0.0. What is interesting to note is that with version 5.0.0 the filesize of the 2-pass tests were smaller than the 1-pass tests. However this is the exact opposite for version 5.0.5.
High Definition Profile Using the profile did increase the filesize, but not as much as I had anticipated. However looking at both frames, I feel that the 1-Pass frame looks better than the 2-pass and the High Definition 2-pass for the car (frame 80), but the 2-Pass frame looked better than the 1-pass and the High Definition 2-pass for the house frame (431). So the increase in filesize seems to not reflect greater image quality (it may however effect other aspects like motion search precision.)
|384 versus 768: Using Quality Based encoding and large frame size like 768 x 576 results in massive files
, but also retains slightly more frame detail.(this is the case with version 5.0.0 and version 5.0.5). 768 x 576
also requires additional CPU time while viewing. So if you require large frame and smallfilesize then a Constant
Bitrate would be recommended.
If you wish to use 384 x 288 frame size, then Quality based encoding will yield you the highest frame quality AND produce the smallest filesize. (this is the case for both version 5.0.0 and 5.0.5)
|MPEG vs Div-x: For Constant Bitrate encoding, Div-x produced higher frame quality and also smaller filesizes. Unless you specifically need to make MPEG files. Div-X CBR will provide you with higher quality and smaller files.|
|Notes on using version 5.0.5: Out of all the Profiles available, I had to select the High Definition Profile
because it was the only one that supported large frame sizes.
Also what was interesting to note is that it doesn't seem 100% backward compatible with version 5.0.0. When I extract frames from the 5.0.0 avi files with version 5.0.5, then compare those frames to the ones extracted with version 5.0.0 installed, they differ in quality!. the version 5.0.0 frames when extracted with version 5.0.0 looked BETTER than those extracted with version 5.0.5.
|With the release of version 5.1.0 of Div-X, it was time to look for an alternative MPEG-4 based codec. The 3 I
chose to compare are 3-ivx, X-Vid and FFVFW. I'm using version 5.0.0 of Div-x as I still feel it retains a slight
frame quality edge over version 5.0.5
I'm testing each codec using two different encoding settings at two different frame sizes. Using a Constant Bitrate of 2000 kbps, and Quality Based encoding at 93% or Quantizer 4. Some codecs report different % values for the same Quantizer 4 value, which makes direct comparisons a little more difficult, but I'll let you decide for yourself which codec does a better job, when you see the frame quality comparisons.
*NOTES* I wanted to use the latest available versions of codecs, however the latest versions of X-Vid seems to have no support for Quality Based (or Quantizer) encoding, and FFVFW is painfully slow. So what I've done is used a previous version of X-Vid for the Quality Based encoding and the latest available beta for the CBR encoding. For FFVFW I've done tests using the current version and the previous version.
I just checked with a person who uses X-Vid more than I and have been informed how to get QB4 encoding with the latest X-Vid. So I'll run some QB tests for that version and post the results soon. ( Thanks to DaveQB )
Throughout this document if you see QB4 written that is my short hand for "1-pass Quality Based 4" and CBR2 or CBR2k is my short hand for "1-pass Constant Bitrate 2000kbps".
|CPU||Intel Tualatin 1.2 ghz|
|Motherboard||ASUS TUSL2-C, Intel 815EP chipset|
|RAM||256mb DIMM, @ 133mhz (PC133)|
|Capture Card||Pinnacle Studio PCTV Rave|
|Capture Settings||PAL, 768 x 576, 25fps, 44.1khz 16bit Stereo Audio. All original footage using Pic Video Quality 18 codec, YUY2 color space.|
|Input Source||Free To Air Broadcast, Analogue PAL, using Tuner on Capture card|
|Operating System||Windows 98SE version 4.10.2222|
|Encoder||Virtual Dub version 1.5.10, using Full processing mode|
|FiLTER NAME||AUTHOR||VERSiON||SETTiNGS USED|
|Virtual Dub internal Resize||Avery Lee||1.5.10 (build 18160)||bicubic A=-1.00|
|Virtual Dub internal Field Swap||Avery Lee||1.5.10 (build 18160)||none|
|Original Video Footage : Duration 1 hour 45 minutes 51 seconds : 158,765 Frames.
Description: Focus of these tests: A) Frame Image Quality, B) Filesize, C) Encoding Speed.
|Video Setting||Encoding Time
|3,448,680,448||Divx 5.0.0||768 x 576||1-pass Quality Based 4 (93%)||6:34|
|2,642,327,552||FFVFW 03/10/28||768 x 576||1-pass Quality Based 4 (93%)||9:41|
|2,633,705,472||FFVFW 03/09/27||768 x 576||1-pass Quality Based 4 (93%)||7:06|
|2,949,136,384||3ivx D4 4.5||768 x 576||1-pass Quality Based 4 (90%)||8:06|
|2,433,085,440||X-Vid 04.10.2002||768 x 576||1-pass Quality Based 4 (93%)||7:26|
|1,860,708,352||X-Vid 26.12.2003||768 x 576||1-pass Quality Based 4 (93%)||10.03|
|1,838,254,080||X-Vid 26.12.2003||768 x 576||1-pass Quality Based 4 (93%)||8:47||Using Turbo Setting|
|1,721,266,176||Divx 5.0.0||768 x 576||1-pass CBR 2000 kbps||6:30|
|1,697,273,856||FFVFW 03.10.28||768 x 576||1-pass CBR 2000 kbps||9:21|
|1,697,273,856||FFVFW 03.09.27||768 x 576||1-pass CBR 2000kbps||6:48|
|1,734,232,064||3ivx D4 4.5||768 x 576||1-pass CBR 2000 kbps||7:58|
|1,697,187,840||X-Vid 04.10.2002||768 x 576||1-pass CBR 2000 kbps||7:43|
|1,694,668,800||X-Vid 26.12.2003||768 x 576||1-pass CBR 2000kbps||10:05|
|1,714,145,284||MPEG 1||768 x 576||1-pass CBR 2000 kbps||34:46|
|848,793,600||Divx 5.0.0||384 x 288||1-pass Quality Based 4 (93%)||4:06||BiCubic Resized down|
|722,894,848||FFVFW 03.09.27||384 x 288||1-pass Quality Based 4 (93%)||4:58||BiCubic Resized down|
|757,161,984||3ivx D4 4.5||384 x 288||1-pass Quality Based 4 (90%)||4:37||BiCubic Resized down|
|718,747,648||X-Vid 04.10.2002||384 x 288||1-pass Quality Based 4 (93%)||4:27||BiCubic Resized down|
|553,111,552||X-Vid 26.12.2003||384 x 288||1-pass Quality Based 4 (93%)||5:12||BiCubic Resized down|
|1,364,035,584||Divx 5.0.0||384 x 288||1-pass CBR 2000 kbps||4:19||BiCubic Resized down|
|1,547,560,960||FFVFW 03.09.27||384 x 288||1-pass CBR 2000 kbps||4:21||BiCubic Resized down|
|1,401,798,656||3ivx D4 4.5||384 x 288||1-pass CBR 2000 kbps||4:51||BiCubic Resized down|
|1,628,284,928||X-Vid 04.10.2002||384 x 288||1-pass CBR 2000 kbps||4:38||BiCubic Resized down|
|1,110,716,416||X-Vid 26.12.2003||384 x 288||1-pass CBR 2000kbps||5:04||BiCubic Resized down|
|FRAME iMAGE QUALiTY: To see some frame image comparisons from TEST 7 and for my views and opinions GOTO THIS PAGE|
|768 x 576 ENCODiNG|
|COMMENTS: FFVFW encoded without errors, however playback of any FFVFW encoded 768 x 576 avi
file displayed serious artefacts at random intervals. I re-ran these tests multiple times and each file
created had varying degree's of this problem. DOWNLOAD Example of this here
(840KB). No other codec tested displayed this problem. The 384 x 288 encoded files all appeared fine. Problem solved.
This is an issue with DECoding and not ENcoding (thanks i4004 ). So to prevent this from occuring use FFDSHOW to decode any FFVFW avi you create
For QB4 encoding the 03/09/27 version was 26.68% faster and produced a 0.3% smaller filesize than the 03/10/28 version. For CBR encoding the 03/09/27 version was 27.3% faster for 0.0% filesize difference than the 03/10/28 version. Frame quality between the two versions was almost identical. I suggest sticking to using the slightly older version
|COMMENTS: Just as a comparison I also created an MPEG-1 test file. I used MPEG-1 instead of MPEG-2 because, MPEG-2 does not support 768 x 576 frame size in TMPGENC. Using TMPGENC, I set the Motion Search Precision to Highest Quality. As you can see this totally kills encoding speed, but is absolutely necessary with MPEG encoding to ensure the least amount of "mosquito" style artefacts which appear due to poor motion detection. It really makes you wonder, that if it took SOO LONG using high motion search precision, how on earth could such algorithms be used during real-time encoding to mpeg (capturing and encoding on-the-fly). Due to the arduous encoding times I did not do a 384 x 288 mpeg sample, however it has been my past experience with MPEG that the filesize using the same CBR 2000 kbps setting would be identical.|
|QUALiTY BASED ENCODiNG: Great for retaining fine detail and very good on motion, but not so good for
filesize. So unless you're archiving some great footage onto a DVD, it's not very practical for footage of long
duration (such as a movie).
Fastest codec is Divx 5.0.0, however it also produced the largest filesize, so speed isn't always everything. Highest compression codec is X-Vid, producing the smallest filesize. FFVFW was a very good balance between encoding speed and filesize, and now that the above issue has been resolved, it would be the recommended codec in this test.
|CONSTANT BiTRATE ENCODiNG Everyone seems to assume that using a Constant Bitrate the filesizes would be equal between the codecs, but this has *never* been my experience, and this test demonstrates that. Fastest codec once again goes to Divx 5.0.0 but it did produce the second highest filesize.|
|384 x 288 ENCODiNG|
|If you consider the number of pixels per framesize. 768 x 576 = 442,368 versus 384 x 288 = 110,592. This means that 768 x 576 is double the frame size, but quadruple the number of pixels. So in theory the 384 x 288 encoding filesizes should be only one quarter those of the 768 x 576 encoded filesizes.. Does this theory hold water?|
|QUALiTY BASED ENCODiNG: This encoding method reflects better the actual frame detail versus the filesize. Take
for example the Div-X encode. The 384 x 288 QB encode is 75.38% smaller than the 768 x 576 (as you would expect as the
frame only contains 25% of the pixels), and the encoding time was 37.56% faster. Is this the same with the other codecs. Lets Check:
So all appear to be close enough to say this theory is right. (The percentages will vary depending on how well the codecs did in the 768 x 576 for compression, but I would classify anything over a 70% reduction to be close enough). Even though Div-X showed the most improvement in compression. X-Vid was still able to beat it for filesize. Quality Based encoding for small frame sizes like this is definitely what I recommend. It is an extremely good balance betwen frame quality and filesize.
|CONSTANT BiTRATE ENCODiNG: Now you would think that using Constant Bitrate settings, the filesizes should be
the same as those from the 768 x 576 tests. After all I set the bitrate to 2000 kbps. However you can see that the filesize
is still relative to the frame size. With the Divx encode the filesize is only 20.75% smaller and encoded 36.9% faster.
I don't believe Constant Bitrate is a viable option for small framesize encoding. If you're encoding small frame files, then filesize must be an issue. If you examine the frame comparison page you'll see that the best CBR 2000kbps could match and possibly just nudge ahead of any QB4 encode in frame quality, but for a filesize increase of 50% ! (using FFVFW as an example) it can *NOT* be justified (imho).
|384 x 288 vs 768 x 576: For a 70 + % filesize reduction when using 384 x 288, that is certainly attractive and doing a frame comparison, I'd say there's no more than a 30 % reduction in fine detail. Ultimately for me though, the duration of the footage (and the importance of the footage) in question would determine which framesize I use. For high importance or short duration, 768 x 576 results in fantastic quality. For long duration or lower importance then 384 x 288 is a very good compromise. You could also try frame sizes inbetween these two (keeping the aspect ratio in mind), to find an even better compromise.|
|RECOMMENDATiONS: This is hard to answer as everyone expects something different from their encodes, so I'll
only give a rough guide, but ultimately do your own tests to determine what codec performs the best on the type
of footage that you capture.
768 x 576 Quality Based Wins, For frame quality the CBR 2000kbps is just too low and too much detail is lost. Quality Based encoding had massive filesizes though, so that may certainly persuade you to either use a slightly smaller framesize, or slightly lower the Quality Based setting. Either way it'd still beat 768 x 576 CBR 2000kbps for image quality.
384 x 288 Quality Based Wins, If you want to sacrifice a little bit of fine detail and have slightly smaller filesizes, then X-Vid would be a good choice. If you're after a little better frame quality and don't mind a slightly larger filesize, then FFVFW wins. Ultimately which codec you choose will be a personal preference, as each codec in the QB4 384 x 288, did a pretty good job.
So to put all the codecs into perspective, I'll compare them based on Div-X's results. As Div-x has been the basis for my other codec tests, this will show if the other codecs are better or worse as a percentage in each area (other than frame quality. Please view the frame comparison page aswell. Image quality is very important).
Speed is in HOURS:MINUTES.
|COMPARiNG All OTHER CODECS TO DiV-X|
|768 x 576 ENCODiNG|
|SPEED||6:34||7.5 % SLOWER||18.9 % SLOWER||11.66 % SLOWER||34.66 % SLOWER|
|FiLESiZE||3.212 GB||23.63 % SMALLER||14.49 % SMALLER||29.45 % SMALLER||46.05 % SMALLER|
|SPEED||6:30||4.4 % SLOWER||18.4 % SLOWER||15.8 % SLOWER||35.5 % SLOWER|
|FiLESiZE||1.603 GB||1.39 % SMALLER||0.75 % LARGER||1.4 % SMALLER||1.5 % SMALLER|
|384 x 288 ENCODiNG|
|SPEED||4:06||17.45 % SLOWER||11.2 % SLOWER||7.87 % SLOWER||21.15 % SLOWER|
|FiLESiZE||0.790 GB||14.8 % SMALLER||10.8 % SMALLER||15.32 % SMALLER||34.85 % SMALLER|
|SPEED||4:19||0.8 % SLOWER||11.0 % SLOWER||6.8 % SLOWER||14.8 % SLOWER|
|FiLESiZE||1.270 GB||11.9 % LARGER||2.7 % LARGER||16.23 % LARGER||18.6 % SMALLER|
|CODEC SETTINGS: Each Codec has a plethora of options, however I must confess I do not understand all of
these settings, nor how they effect the encoding. So once the codecs were installed I only selected CBR & set the bitrate
or selected QB and set the quality factor or Quantizer value. All other settings were left at the default settings.
This may or may not be the most optimum settings for each codec, but as the information supplied with the codecs is very sparse
I'm pretty sure this would be the way most users use the codecs, and therefore reflects obtainable comparisons if you were
to conduct your own tests.
To see what settings I used for each Codec move your mouse over the notepad icon under each codec name in the following table
|Codec Configuration Settings|
|After some discussions with i4004, I decided to do some further testing using different Quantizer
settings to determine for myself what impact they have on encoding.
As these options are not covered in all the codecs, I'm only re-running the tests using FFVFW 03/09/27 and X-Vid 26.12.2003 (using Turbo setting)
To put these values into perspective compare them to the above results for TEST 7
All the FFVFW and X-Vid encodes in TEST 7 were done using H.263 Quantizer type.
I may expand on this test and try different Quantizer values for P Frames min and max if time permits
File - Information
|Type||P Frame Min||P Frame Max||Average Bitrate|
|2,255,142,912||FFVFW||768 x 576||QB 4 (93%)||6:55||MPEG||2||31||2700 kbps|
|1,697,273,856||FFVFW||768 x 576||CBR 2k||7:09||MPEG||2||31||2000 kbps|
|685,877,248||FFVFW||384 x 288||QB 4 (93%)||4:16||MPEG||2||31||726 kbps|
|1,416,554,496||FFVFW||384 x 288||CBR 2k||4:29||MPEG||2||31||1647 kbps|
|1,748,729,856||X-Vid||768 x 576||QB4 (93%)||9:58||MPEG||2||31||2065 kbps|
|1,694,763,008||X-Vid||768 x 576||CBR 2k||10:08||MPEG||2||31||1997 kbps|
|541,362,176||X-Vid||384 x 288||QB4 (93%)||4:38||MPEG||2||31||544 kbps|
|1,104,029,696||X-Vid||384 x 288||CBR 2k||4:48||MPEG||2||31||1253 kbps|
|There seems to be a clear difference between the two Quantization types. MPEG at these resolutions and quantizer
/ bitrate values have all shown improvements in sharpness
How well they did at different frame sizes and encoding methods will be covered shortly.
|MPEG vs H.263|
|Boy this was interesting. I didn't expect such results, but as you can see using QB4 encoding
with MPEG was a win/win/win situation. Filesize is smaller, encoding time was faster and frame quality is better
Once all tests are completed sample frame images will be added to the Frame Image Quality Page from Test 7
|768 x 576 ENCODiNG|
|QUALiTY BASED ENCODiNG: There are general increases in detail throughout the whole frame with both FFVFW and X-Vid. In the above TEST 7, I classified Div-X as winning, but now I'd have to say that is no longer the case. The fact that FFVFW using MPEG type Quantizer not only gained additional frame detail and sharpness it also produced an even smaller filesize and was faster to encode. (see below table for % differences). I RECOMMEND MPEG instead of H.263 for 768 x 576 QB Encoding.|
|CONSTANT BiTRATE ENCODiNG: FFVFW shows clear signs of improvement in frame quality, but still doesn't equal that of Div-X from Test 7. X-Vid also shows additional sharpness, but it's very inferior to FFVFW. (massive amounts of detail loss in the fire and the chopper).|
|384 x 288 ENCODiNG|
|QUALiTY BASED ENCODiNG: Faster to encode and produces smaller filesizes. Frame detail and sharpness gets
a slight boost aswell.
Enabling post-processing can mask (or cover up) these artefacts, but it will also reduce fine detail on the frame. So it maybe better off just using H.263 with post-processing disabled.. As mentioned earlier it will be a personal preference.
X-Vid seemed to introduce noise into some parts of the frame. So some areas of the frame look better, but others look worse. So I would say using MPEG with X-Vid for this test is a 50/50 (increase vs decrease) . Check out what it did to the top of the chopper door and the turbine. However X-Vid did produce the smallest filesize, so that would leave you the ability to increase the quality factor. For this test though I would choose FFVFW with MPEG.
|CONSTANT BiTRATE ENCODiNG: Once again MPEG provided additional sharpness for both FFVFW and X-Vid, and this time it is very difficult to identify differences. FFVFW shows additional sharpness in the fire than X-Vid, but this is minimal, and considering the filesize saving X-Vid is a good choice. However as the filesize for this test is still too large for a single 700mb cd-r, both codecs would require the use of 2 cd's anyways, so that would easily make me select FFVFW for the slight addition of sharpness and for slightly faster encoding times. Oh MPEG wins.|
|The Below table shows the differences at a glance when comparing MPEG type encodes to H.263 type encodes.|
|HOW DOES QUANTiZER TYPE MPEG COMPARE AGAiNST H.263|
|768 x 576 ENCODiNG||384 x 288 ENCODiNG|
|SPEED||7.5 % FASTER||11.87 % SLOWER||14.09 % FASTER||10.90 % FASTER|
|FiLESiZE||14.37 % SMALLER||4.87 % SMALLER||5.12 % SMALLER||2.12 % SMALLER|
|QUALiTY||BETTER||BETTER||BETTER||50 / 50|
|SPEED||4.90 % SLOWER||2.10 % SLOWER||2.97 % SLOWER||5.26 % FASTER|
|FiLESiZE||0.0 % EQUAL||0.01 % LARGER||8.47 % SMALLER||0.60 % SMALLER|
|CORRECTiONS, MODiFiCATiONS & EDiTS|
|21st January, 2003||Identified typo with filesize of FFVFW 384 x 288 QB4, I had 772,894,848 instead of 722,894,848. This made all comparison % calculations incorrect, which have now been re-calculated.|
Due to the volume of additional tests I've done with Codecs, Encoding and with video capturing in general, it's too much information for this site to handle.
So I have setup a dedicated site. Click on the Aussie Video Search Logo to go there.
(This will break out of any frames)