WHiCH PROCESSiNG METHOD iS MORE EFFiCiENT.

If you like capturing to a lossless codec first, then you obviously like higher quality (or at the very least the Option of having higher quality), than if you simply capture and real-time encode to a lossy format (such as divx or mpeg).

However :

Is the post-processing method you are using the most efficient?

This page will hopefully help answer that. Even though computers are getting faster and faster most people still hate waiting for post-processing to be completed, so every minute *may* count. How is your computer spending that time, and if it is spending more time on a particular task, does that have other benefits?...(such as increased frame quality or reduced filesize).


Test Platform

COMPONENT SPECiFiCATiON
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
Encoders Virtual Dub version 1.5.10.
AviSynth version 2.55


TEST1 - METHODS OF RESiZiNG

WHY RESiZE? : Capturing at full resolution (which for me is 768 x 576) yields great quality, but unless you have a DVD media for storage, the filesizes are too large for a single CD-R. So I prefer to resize down to 384 x 288 during Post-processing. This yields a ~ 70% filesize saving, for a ~ 40% reduction in frame detail. This is acceptable to me, but it does depend on the importance of the footage. So for high importance, I leave at full resolution, but for processing shows I only intend to watch once or store temporarily, small framesize works best. If you wish to see an accurate comparison between capturing and post processing to different frame sizes, feel free to visit my Frame Size Comparison Page

So the main questions are

Which Resizing Method is the Fastest, Yields the Best Frame Quality and produces the smallest Filesize ?.

Another issue is briefly addressed aswell. AviSynth manual states there maybe a performance benefit from cropping before resizing, so I investigate this aswell.

SOURCE FOOTAGE: This was a widescreen broadcast, duration of 1 hour 20 minutes and 16 seconds. It was a progressive scan broadcast and therefore required no de-interlacing. However due to my capture card, the footage does require a Field Swap, which I perform in Avisynth for all tests.

For cropping I have decided to remove the top and bottom black bands from the footage. So for Cropping After tests, I will be resizing down to 384 x 288 and then cropping to 384 x 256. For the Cropping before tests, I will be cropping to 768 x 512, and then resizing to 384 x 256.

All files are encoded with Divx verison 5.00 using Quality Based 93% (QB4) Encoding. This I feel yields the most acceptable frame quality versus filesize.

If you wish to see what AviSynth Script and or Virtual Dub Script I use for each test, just hovver your mouse over the Script Image for that test and it will popup.

WHY CROP? : You maybe asking Why bother cropping?.. Well the simple answer is when encoding with MPEG4 based codecs, the framesize has a direct relationship to the filesize. The larger the frame the larger the filesize. This is also true for Constant Bitrate Encoding, but not to the same degree as using Quality Based Encoding. Visit my MPEG4 Codec Comparison Tests for more accurate comparisons between CBR and QB encoding.

Just as a comparison I have done two tests which have not been cropped, One in Avisynth and one in Virtual dub. You can see the filesize savings are not huge, but if there was noise in these unused screen portions (which are visible on cable services), then that will drastically effect the encoding efficiency.

FiLESiZE ENCODiNG
TiME
ENCODiNG
PROGRAM
RESiZE METHOD
SETTiNGS
CROPPING SCRiPT
645,711,872 2:39 AviSynth Lanczos After SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()
 LanczosResize(384,288)
 crop(0,16,-0,-16)
645,711,872 2:25 AviSynth Lanczos Before SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()
 LanczosResize(384,256,0,32,768,512)

658,655,232 2:15 AviSynth Precise Bicubic (1) After SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()
 BicubicResize(384,288,0,1)
 crop(0,16,-0,-16)
658,655,232 2:15 AviSynth Precise Bicubic (1) Before SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()
 BicubicResize(384,256,0,1,0,32,768,512)
632,666,112 2:19 AviSynth Precise Bicubic (0.75) After SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()
 BicubicResize(384,288,0,0.75)
 crop(0,16,-0,-16)
530,558,976 2:08 AviSynth Precise Bilinear After SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()
 BilinearResize(384,288)
 crop(0,16,-0,-16)
530,558,976 2:06 AviSynth Precise Bilinear Before SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()
 BilinearResize(384,256,0,32,768,512)

625,942,528 3:40 Virtual Dub Precise Bicubic (0.75) After SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()

 VIRTUAL DUB JOB SCRIPT SETTINGS

 VirtualDub.video.filters.Add('resize');
 VirtualDub.video.filters.instance[0].Config(384,288,4);
 VirtualDub.video.filters.Add('null transform');
 VirtualDub.video.filters.instance[1].SetClipping(0,16,0,16);
650,065,920 3:38 Virtual Dub Precise Bicubic (1) After SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()

 VIRTUAL DUB JOB SCRIPT SETTINGS

 VirtualDub.video.filters.Add('resize');
 VirtualDub.video.filters.instance[0].Config(384,288,6);
 VirtualDub.video.filters.Add('null transform');
 VirtualDub.video.filters.instance[1].SetClipping(0,16,0,16);
650,168,320 4:03 Virtual Dub Precise Bicubic (1) Before SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()

 VIRTUAL DUB JOB SCRIPT SETTINGS

 VirtualDub.video.filters.Add('null transform');
 VirtualDub.video.filters.instance[0].SetClipping(0,32,0,32);
 VirtualDub.video.filters.instance[0].Config(0,16);
 VirtualDub.video.filters.Add('resize');
 VirtualDub.video.filters.instance[1].Config(384,256,6);
560,709,632 3:26 Virtual Dub Precise Bilinear After SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()

 VIRTUAL DUB JOB SCRIPT SETTINGS

 VirtualDub.video.filters.Add('resize');
 VirtualDub.video.filters.instance[0].Config(384,288,3);
 VirtualDub.video.filters.Add('null transform');
 VirtualDub.video.filters.instance[1].SetClipping(0,16,0,16);

565,835,776 2:01 AviSynth Reduce By 2 After SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()
 ReduceBy2()
 crop(0,16,-0,-16)

662,577,152 2:21 AviSynth Precise Bicubic (1) No Crop SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()
 BicubicResize(384,288,0,1)
653,867,008 3:28 Virtual Dub Precise Bicubic (1) No Crop SegmentedAVISource('F:\PIC18-BlackDog_1.avi')
 swapfields()

 VIRTUAL DUB JOB SCRIPT SETTINGS

 VirtualDub.video.filters.Add('resize');
 VirtualDub.video.filters.instance[0].Config(384,288,6);


FASTEST_RESiZE METHOD
PROGRAM: Well without a doubt using AviSynth is certainly faster at resizing than Virtual dub. This holds true for all methods of resizing. So if speed holds the highest importance to you, then Avisynth is the way to go.
METHOD: Reduce by 2 had to win, as it's the most basic method of cutting the framesize in half. So if you want maximum speed at the sacrifice of frame quality then this would be the quickest method.
SMALLEST FiLESiZE
PROGRAM: Virtual Dub wins in all methods except Precise Bilinear. So if filesize is important and you use any method other than Precise Bilinear then use Virtual dub. If you use Precise Bilinear then use Avisynth.
METHOD: I really did except Reduce by 2 to win, but AviSynth and Bilinear did.
HiGHEST FRAME QUALiTY
Speed and filesize maybe important, but Frame Quality holds the highest priority for me (unless the footage is just watch once and then delete). So if it is footage you wish to archive, then Virtual dub and Precise Bicubic A=-1.00 wins.

This produced the sharpest quality and retained the most fine detail. Lanczos would come in second with Precise Bicubic A=-0.75 being almost equal.

Just one note, depending on your footage content you may find that reducing the framesize, Precise Bilinear may do a better job and yield less "ringing" on the frame, or if you prefer a slightly sharper frame than Precise Bilinear but slightly softer than Precise Bicubic A=-1.00, then you may find Precise Bicubic a=-0.75 (or a=-0.60) works best for you.

It really is a personal preference combined with the type of footage you are encoding.
CROPPiNG
AviSynth A 14 minute saving was gained when using Cropping Before with Lanczos and Avisynth. There was also a 2 minute saving when using Precise Bilinear resizing aswell. There was no filesize benefit, nor was there any frame quality benefits. All Before vs After frame comparisons were identical.
Virtual Dub Well there's no option. For whatever reason, cropping After is so much more efficient with a saving of 25 minutes, and the filesize is slightly smaller.



TEST2 - METHODS OF ENCODiNG WiTH ViRTUAL DUB

Ok, so no matter which resizing method you use, if you choose to do all your processing in AviSynth then speed is probably your main goal. Now this allows you the option of running Virtual Dub in Fast Recompress mode as you do not need to use any Virtual Dub filters.

Is Fast ReCompress any faster than Full Processing Mode ?

( Even though Full processing Mode is used, there are no filters loaded. However I've been informed by i4004 that using Virtual dub in Full Processing mode performs a color space conversion to RGB, but Fast ReCompress does not. So this may influence your choice. It will just depend on what you deem as more important. )

I chose a different piece of footage (slightly longer) for this test.

SOURCE FOOTAGE: This was a widescreen broadcast, duration of 1 hour 37 minutes and 44 seconds. It was a progressive scan broadcast and therefore required no de-interlacing.

All processing was accomplished with Avisynth. (fieldswap and bicubic resize), so Virtual Dub only had to do the encoding to Divx.

FiLESiZE ENCODiNG TiME ViRTUAL DUB MODE
491,233,280 bytes 2:39 Fast ReCompress
485,888,000 bytes 2:45 Full Processing Mode
RESULT
Well there you go, Fast ReCompress is faster, by only 6 minutes, however it did produce a slightly larger filesize, which was expected after seeing the results from TEST1. Faster processing usually increases filesize.

So is Fast ReCompress worth it?.. IMHO I'd say no. I'd rather have a slight filesize saving than slightly faster encode time. Doing a frame comparison between Full Processing and Fast ReCompress there is a slight variation with benefits going both ways. If you wish to see for yourself, here is a frame comparions Fast Recompress and Full Processing Check out the man far left of screen, behind him is a lady with a checkered skirt on. In Full processing, that checker pattern is lots softer, so are the creases on his coat.

So the conversion to RGB is effecting frame quality, but during normal playback you'd never notice these small reductions, which would also result in the slight filesize reduction.



TEST3 - METHODS OF ENCODiNG TO MPEG using TMPGENC

Ok, so not everyone wants to encode to Div-x. Some wish to encode to MPEG for playback in DVD players, or portable DVD players

So, this test tries to identify ways of increasing the encoding speed of TMPGENC but still retain good frame quality.

The footage I used for this test is the same footage from the MPEG4 TEST7 however to reduce the time required to run all these tests, I only used the first 30 minutes.

SOURCE FOOTAGE: 30 minutes (45,000 frames). This was a progressive scan broadcastand therefore required no de-interlacing.

All processing was accomplished with Avisynth. (fieldswap and bicubic resize). Virtual Dub was not used.

Input source was 768 x 576, however MPEG2 and DVD standards do not support this. I have two official standards:

PAL High Res MPEG-2 720 x 576, 25fps
PAL Low Res MPEG-2 352 x 288, 25fps

So I chose to encode using those frame sizes. This means the input source was set to 4:3 and the output source was set to 1:1 aspect ratios. Secondly I chose 4000kbps for all tests to aid in easier direct comparisons, however using smaller framesize encoding, there is no need to use a bitrate that high if you wish to fit more on your DVD media. the TMPGENC standard for low res PAL DVD only goes upto 1,850kbps, so before you do any tests like this for yourself just ensure what your equipment supports.

FiLESiZE iNPUT FRAMESiZE OUTPUT FRAMESiZE ENCODiNG
TiME
TMPGENC SETTiNGS
GOP MOTiON SEARCH
PRECiSiON
I Frame P Frame B Frame
967,303,172 384 x 288 352 x 288 1:01.31 1 0 0 Normal
967,303,172 384 x 288 352 x 288 1:10.59 1 0 0 Lowest
967,303,172 384 x 288 352 x 288 1:18.36 1 5 2 Normal
967,303,172 384 x 288 352 x 288 1:11.30 1 5 2 Lowest
967,303,172 384 x 288 352 x 288 1:14.09 1 14 0 Normal
967,303,172 384 x 288 352 x 288 1:14.09 1 14 0 Lowest

967,303,172 384 x 288 720 x 576 2:31.14 1 5 2 Normal

967,305,220 768 x 576 720 x 576 2:19.23 1 0 0 Normal
967,305,220 768 x 576 720 x 576 2:19.22 1 0 0 Lowest
967,303,172 768 x 576 720 x 576 3:24.10 1 5 2 Normal
967,303,172 768 x 576 720 x 576 2:51.28 1 5 2 Lowest
967,303,172 768 x 576 720 x 576 3:05.00 1 14 0 Normal
RESULT
Well that is pretty clear. The earlier in your post-processing that you reduce the frame size, the faster TMPGENC can encode. If you get TMPGENC to resize back to 720 x 576 it still works out faster than passing TMPGENC the full frame avi file. (when comparing the same IPB settings)
352 x 288
Well that is pretty clear aswell. Considerably faster at encoding than all the 720 x 576 encodes.

By removing B-Frames from the encoding process you can gain an some additional processing speed. So in the above test using Just I and P frames, you gained 4 minutes, and by using just I Frames you can gain an additional 13 minutes.

When you take into account frame quality for all of the 352 encodes were fairly even, there's no point in using P or B Frames unless you're going to use low bitrates.

The same goes for Motion Search Precision. There was no speed benefit in any of the tests that didn't use B Frames.

I would select the No P or B Frame encode (1 0 0), with Motion Search Precision set to Normal.
720 x 576
Passing TMPGENC 384 x 288 and having it resize upto 720 x 576 was certainly the fastest approach, but this does result in a slightly softer frame, so if this is footage you wish to archive, then pass TMPGENC the full frame avi.

By removing B-Frames from the encoding process you once again save a bit of time, (19 minutes), and I feel the frame quality is actually better with the 1,14,0 encode than the 1,5,2 encode. However removing P Frames you gain an additional 46 minutes, but the frame quality takes a considerable hit. So unless you want to increase the bitrate it is not suggested that you drop P frames when encoding at this resolution.

Now for Motion Search Precision, there was no speed benefit in any of the tests that didn't use P or B Frames, however when set to Lowest for the test that used P and B frames, the benefit was a 30minute reduction, but at huge expense to frame quality.

I would select the no B Frame encode (1 14 0) with Motion Search precision set to atleast Normal.
NOTES
GOP STRUCTURE: You maybe wondering how I came up with those I P and B values? Well if you load TMPGENC, click on Settings, then GOP Structure you should see 3 buttons I Picture Only, I,P Picture Only and Standard.

I Picture Only is 1,0,0
I,P Picture Only is 1,14,0
and Standard is 1,5,2
COLOURS: A GREEN cell background indicates this is the most efficient in that category (ie speed, or filesize)
A RED cell background indicates this is the most efficient in that category but is not recommended due to drastically effecting another criteria (such as frame quality).



CONCLUSiON - FRAME COMPARiSONS

So the results are in, but sometimes they don't mean sh!t unless you have something to compare with so you can make up your own conclusions. So here are single frame captures from each of the above test samples

In Frame A, you will be able to see the loss of detail in the face, hair and cabinet on her right. In Frame B, you will be able to see the detail loss in the girls face and weave of her coat. (check her right shoulder, arm)

Frame A and B are at actual size, so if you wish to enlarge (or zoom) them you will be able to see the differences easier. Or simply view them at full screen, in whatever picture viewer you use.

In Frame Sample for Test 3, have a look at the detail loss on the top of the Helicopter roof and for compression block artefacts. All images have been resized to 720 x 576 to make direct comparisons easier.

FRAME SAMPLE A FRAME SAMPLE B
AviSynth Lanczos
AviSynth Precise Bicubic 1
AviSynth Precise Bicubic 0.75
AviSynth Precise Bilinear
AviSynth Reduce by 2
Virtual Dub Precise Bicubic 1
Virtual Dub Precise Bicubic 0.75
Virtual Dub Precise Bilinear
AviSynth Lanczos
AviSynth Precise Bicubic 1
AviSynth Precise Bicubic 0.75
AviSynth Precise Bilinear
AviSynth Reduce by 2
Virtual Dub Precise Bicubic 1
Virtual Dub Precise Bicubic 0.75
Virtual Dub Precise Bilinear
FRAME SAMPLE FOR TEST 3
384 - 352 Lowest 1 5 2
384 - 352 Normal 1 5 2
384 - 352 Normal 1 14 0
384 - 352 Normal 1 0 0
384 - 720 Normal 1 5 2
768 - 720 Lowest 1 5 2
768 - 720 Normal 1 5 2
768 - 720 Normal 1 14 0
768 - 720 Normal 1 0 0
768 - 720 Lowest 1 0 0

This Web Site, requires
Microsoft Internet Explorer with JavaScript And Frames Support
Best viewed in 1024 x 768 resolution

This Page was:
Created on: 20th May 2oo4
Last updated on: 24th July 2oo4

(C) Narler

If you didn't get to this page from my Main Page, Click here