WHAT FRAME SiZE YiELDS THE HiGHEST QUALiTY.
But what are the other advantages / dis-advantages associated with that frame size

Now before you read any further, there's a few things that I think you should consider before you conduct your own tests. Also once you can answer the following questions, then the rest of the information on this page I feel will be of more benefit to you.

How fast the CPU is in your capture PC ?
Increasing the frame size will require a faster CPU for capturing AND playback.

How large (filesize) do you want your final avi to be ?
To keep the quality high, I prefer to use Quality Based encoding settings with Div-X, but in doing this, increasing the frame size also increases the filesize.

How intelligent is the player you use to watch your avi files ?
This is very relevant, because it maybe more beneficial when capturing in out-of-aspect ratio frame sizes, to not resize in post-encoding, but to let the player do the resizing during playback. For this reason an intelligent media player is required. I use and highly recommend ZOOM Player.

How long do you wish to wait for post-processing to finish ?
Using filters and increasing frame size, drastically slows down post-processing. Some people really don't like to wait very long between capturing and watching. But for me, post-processing duration is of no concern. I'm only concerned with frame image format and filesize.


After a user on one of the forums I participate in, posted a link to www.100fps.com, I had always tried to capture non-interlaced, simply because all the de-interlacing filters I'd tried didn't really yield me the results I was after. Sure there are issues with resizing (bicubic or bilinear), but the disadvantages of bicubic versus the sharpness and clarity that it yielded were always minimal (imho). But after going to 100fps and reading about separating fields to make 50fps avi files, I thought I would give it a try and do my own comparisons between non-interlaced and interlaced capturing. I especially wanted to see if there was any difference in capturing at, 384 x 288 25fps non interlaced, 768 x 288 25fps non interlaced versus 768 x 576 interlaced, then separating and resizing down to 384 x 288. In previous test there were huge benefits from capturing at 768 x 288 versus 384 x 288 (See HERE, so would 768 x 576 interlaced and resized down to 384 x 288 be better than 768 x 288 resized down?.. Also I'll try to cover all disadvantages aswell.


But first off, one thing on 100fps.com that I found a concern, was the 320 x 240 versus 384 x 288 frame comparison. I'm not sure how their 384 x 288 image was obtained but in all tests I've done, higher frame size has always yielded additional data, so doing 2 captures at said resolutions using identical footage. I get the below, so you can decide for yourself. In the 384 x 288 image however I see more and brighter stars, but no where near the variation of difference as see on 100fps.com. (both images are completely unedited and have been ripped directly from the Huffyuv footage, stored as jpeg quality 10). (Source footage was a 4:3 25fps PAL DVD.)

Huffyuv frame from a 320 x 240 capture Huffyuv frame from a 384 x 288 capture
320 x 240 capture 384 x 288 capture


OK.. BRiNG ON THE COMPARiSONS.

The source footage was from a PAL (region 4) DVD which is in 4:3 aspect ratio. Each framesize below was captured at that resolution using the exact same footage. All footage was encoded with Div-X version 5.00 using Quality Based 4. All files include audio encoded with LAME at 128kbps (captured at 44.1khz 16bit STEREO). The reason Audio was included (even though this is a frame image quality test), is because I also wanted to monitor CPU usage during playback, and I doubt anyone would bother to capture footage without audio, so I wanted accurate CPU usage figures for a realistic capture.

Duration of footage is 1 minute and 15 seconds. This length was chosen because it covered numerous scene changes, which included fast motion, slow motion, static background and fine detail.

Capture Settings. All tests were captured using Huffyuv version 2.1.1 with YUY2 frame image format, on a Pinnacle PCTV RAVE PCI card.

To make the following table a little smaller, I'll list the filters used and their settings separately. However All filters listed in the main table are in order of use.


FiLTERS USED

FiLTER NAME AUTHOR VERSiON SETTiNGS USED
Virtual Dub internal Resize Avery Lee 1.5.3 (build 16250) bicubic A=-1.00
Smart Deinterlace Donald Graft 2.7 beta 2 Field only differencing, Phase Shift
Avisynth Edwin van Eggelen 1.0 beta5 Seperate Fields
Deinterlace - smooth Gunnar Thalin 1.1 Default settings 24/20/35/80


FiLESiZE and POST ENCODiNG RESULTS

Here you can see the encoding time and what filters were used


iNPUT SPECiFiCATiONS POST ENCODiNG OUTPUT SPECiFiCATiONS
FRAME SiZE INTERLACED FiLTERS TiME
Minutes
FRAME SiZE FRAME RATE FiLESiZE
BELOW CAPTURES ARE ALL NON-iNTERLACED. (Single field captures)
320x240 NO - none - 1 320x240 25 fps 4,718,592.bytes
  • Virtual Dub Resize
  • 1 384x288 25 fps 5,040,128.bytes
  • Virtual Dub Resize
  • 3 768x576 25 fps 11,325,440.bytes
    384x288 NO - none - 1 384x288 25 fps 5,750,784.bytes
  • Virtual Dub Resize
  • 3 768x576 25 fps 11,778,048.bytes
    768x288 NO - none - 3 768x288 25 fps 11,755,520.bytes
  • Virtual Dub Resize
  • 1 384x288 25 fps 7,268,352.bytes
    4 768x576 25 fps 16,271,360.bytes
    BELOW CAPTURES ARE ALL iNTERLACED. (both fields captured), Output files are all NON-iNTERLACED
    384x576 YES
  • Smart Deinterlace
  • 3 384x576 25 fps 12,611,584.bytes
  • Smart Deinterlace
  • Virtual Dub Resize
  • 2 384x288 25 fps 6,807,552.bytes
  • Smart Deinterlace
  • Virtual Dub Resize
  • 4 768x576 25 fps 19,036,160.bytes
  • Avisynth
  • Deinterlace - smooth
  • 9 384x576 50 fps 18,530,304.bytes
  • Avisynth
  • Deinterlace - smooth
  • Virtual Dub Resize
  • 10 384x288 50 fps 9,738,240.bytes
  • Avisynth
  • Deinterlace - smooth
  • Virtual Dub Resize
  • 12 768x576 50 fps 29,052,928.bytes
    640x480 YES
  • Smart Deinterlace
  • 4 640x480 25 fps 12,849,152.bytes
  • Smart Deinterlace
  • Virtual Dub Resize
  • 4 384x288 25 fps 5,771,264.bytes
  • Smart Deinterlace
  • Virtual Dub Resize
  • 4 768x576 25 fps 14,536,704.bytes
  • Avisynth
  • Deinterlace - smooth
  • 14 640x480 50 fps 19,742,720.bytes
  • Avisynth
  • Deinterlace - smooth
  • Virtual Dub Resize
  • 13 384x288 50 fps 8,321,024.bytes
  • Avisynth
  • Deinterlace - smooth
  • Virtual Dub Resize
  • 15 768x576 50 fps 22,061,056.bytes
    768x576 YES
  • Smart Deinterlace
  • 5 768x576 25 fps 20,436,992.bytes
  • Smart Deinterlace
  • Virtual Dub Resize
  • 4 384x288 25 fps 6,416,384.bytes
  • Avisynth
  • Deinterlace - smooth
  • 19 768x576 50 fps 31,143,936.bytes
  • Avisynth
  • Deinterlace - smooth
  • Virtual Dub Resize
  • 18 384x288 50 fps 9,209,856.bytes


    Now I'm sure you're wondering, "All that information is fine, but how do those files playback on an average computer"?.. (ok well maybe you're not thinking that but here's the data just incase you did want to know.) Playback was on a Pentium III 1.2Ghz pc, with 384MB PC133 SDRAM, using Win98SE and Zoom Player. Where the footage is out of 4:3 aspect ratio, I'm using Zoom Player to adjust that during playback to 4:3.


    CPU PLAYBACK USAGE
    FRAME SIZE 25 FPS 50 FPS
    320 x 240 CPU Usage during playback on a Pentium III 1.2GHZ. Graph shows playback duration of 40 seconds, using Windows 98SE and Zoom Player - n/a -
    384 x 288 CPU Usage during playback on a Pentium III 1.2GHZ. Graph shows playback duration of 40 seconds, using Windows 98SE and Zoom Player CPU Usage during playback on a Pentium III 1.2GHZ. Graph shows playback duration of 40 seconds, using Windows 98SE and Zoom Player
    384 x 576 CPU Usage during playback on a Pentium III 1.2GHZ. Graph shows playback duration of 40 seconds, using Windows 98SE and Zoom Player CPU Usage during playback on a Pentium III 1.2GHZ. Graph shows playback duration of 40 seconds, using Windows 98SE and Zoom Player
    768 x 288 CPU Usage during playback on a Pentium III 1.2GHZ. Graph shows playback duration of 40 seconds, using Windows 98SE and Zoom Player - n/a -
    640 x 480 CPU Usage during playback on a Pentium III 1.2GHZ. Graph shows playback duration of 40 seconds, using Windows 98SE and Zoom Player CPU Usage during playback on a Pentium III 1.2GHZ. Graph shows playback duration of 40 seconds, using Windows 98SE and Zoom Player
    768 x 576 CPU Usage during playback on a Pentium III 1.2GHZ. Graph shows playback duration of 40 seconds, using Windows 98SE and Zoom Player CPU Usage during playback on a Pentium III 1.2GHZ. Graph shows playback duration of 40 seconds, using Windows 98SE and Zoom Player


    NOTES: If your CPU usage is higher than what is reported here, then I would suggest you adjust the post processing with Div-X. To see what I'm talking about and how it effects CPU usage, PLEASE VIEW THIS IMAGE. By adjusting the post processing slider, I have not noticed any drop in image quality, but there is a substantial drop in cpu usage. Infact comparing the MAX to the MIN setting during playback, the MAX setting seems to actually smooth over fine detail in small frame avi files (such as 384 x 288). Check this out for yourself. When you view any of the above 384 x 288 samples, check out the wall pattern/detail in the first interview (bald man with glasses). On the MIN setting the lines on the right of the wall are still there (compression block artefacts are visible though), but on the MAX setting, the pattern is smoothed over and almost gone (compression block artefacts are still visible). On larger framesize avi files the MIN/MAX settings didn't have such a profound effect.


    OK.. BUT iS THERE REALLY ANY DiFFERENCE iN QUALiTY BETWEEN THOSE FRAME SiZES?
    Take a look for yourself in the below slideshow


    300% zOOm (bicubic resize) OF 768 x 576 SAMPLES to show Resize Artefacts and detail loss
    FRAME A FRAME B
           
    The above images may appear to move around, but this is expected, because at each capture resolution, the tv-card has to perform the resizing, and in some captures it only uses one field, so which field it uses may result in "bobbing" (ie if it uses the top field or the bottom field each will be offset by one line)


    THE TEST SAMPLE FOOTAGE TOO SHORT FOR YOU?
    Ok, I know what you're thinking, "So how does all this work out on a real life length capture"

    As a test, I captured using the onboard tuner, from a Free-To-Air Terestrial broadcast a 1 hour show and after removing advertisements, the final duration was 41 minutes 45 seconds.

    So how do filesizes look. Now I have only done the bicubic resize up to 768 x 576, because there is no benefit at all with using Constant Bitrate encoding at 384 x 288. Quality Based will yield you smaller filesizes. See Here For additional codec comparisons

    I'm assuming you've looked at the frame comparison pages, and you would have seen that I selected 384 x 576 as being the best choice. (It doesn't use as much CPU as 640 x 480 or 768 x 576, but still yields the quality almost equal to 768 x 576) So the below test is using 384 x 576.

    I also wanted to see the comparison between Quality Based encoding and Constant Bitrate. All files encoded with Div-X Version 5.00


    POST ENCODiNG OUTPUT SPECiFiCATiONS
    FiLTERS FRAME SiZE FRAME RATE FiLESiZE iMAGE QUALiTY
    DiV-X, QUALiTY BASED 93% ENCODiNG
  • Smart Deinterlace
  • Virtual Dub Resize
  • 384x288 25 fps 260,251,648.bytes AVERAGE. Worse than the 50fps 384 x 288 version, but still better than capturing at 384 x 288.
  • Smart Deinterlace
  • Virtual Dub Resize
  • 768x576 25 fps 793,765,888.bytes GOOD. Slight appearance of tearing, which could be attributed to the deinterlace filter, but overall better than 384 x 288
  • Avisynth
  • Deinterlace - smooth
  • Virtual Dub Resize
  • 384x288 50 fps 370,235,392.bytes AVERAGE. Not quite a sharp as 768 x 288 bicubic resized, but it also doesn't suffer from massive resizing artefacts. This is the option I'd RECOMMEND for making 384 x 288 avi files.
  • Avisynth
  • Deinterlace - smooth
  • Virtual Dub Resize
  • 768x576 50 fps 1,181,822,976.bytes OUTSTANDiNG. With finetuning of the deinterlace smooth filter this can look as good as 768 x 576. But OUWCH.. the filesize is certainly a limiting factor.
    DiV-X, CONSTANT BiTRATE of 1,500kbps (using 2-pass mode) ENCODiNG
  • Smart Deinterlace
  • Virtual Dub Resize
  • 768x576 25 fps 513,038,336.bytes BAD. This is certainly inferior to the 50fps 384 x 288 Quality Based version (when viewed at full screen). Massive compression block artefacts everywhere and each frame seems to have what looks like a "heat haze" about it.
  • Avisynth
  • Deinterlace - smooth
  • Virtual Dub Resize
  • 768x576 50 fps 515,442,688.bytes BAD. This is only marginally better than the above CBR version.
    DiV-X, CONSTANT BiTRATE of 2,000kbps (using 2-pass mode) ENCODiNG
  • Smart Deinterlace
  • Virtual Dub Resize
  • 768x576 25 fps 669,640,704.bytes VERY GOOD. This is so much better than the 1,500kbps versions. So if you want a compromize between maximum image quality and Filesize, this is the option I'd RECOMMEND for making 768 x 576 avi files.
    DiV-X, CONSTANT BiTRATE of 2,000kbps (using 1-pass mode) ENCODiNG
  • Smart Deinterlace
  • Virtual Dub Resize
  • 768x576 25 fps 672,868,352.bytes VERY GOOD. Slightly larger filesize than the 2-Pass version, and only a slight reduction in image quality. So if shorter post-processing time is more important to you, at the sacrifice of a small amount of image quality, and slightly larger files then this maybe the option for you.


    ADVANTAGES vs DiS-ADVANTAGES

    FORMAT ADVANTAGES DiS-ADVANTAGES
    320x240
  • Uses Least amount of CPU time (capture and playback)
  • Fast to post-encode (but not much faster than 384 x 288)
  • Produces the smallest filesizes (when using QB encoding)
  • loss of fine detail, so viewing at desktop resolution will show compression block artefacts
  • Image looks slightly blurred or soft
  • Slight loss of detail also in high contrast areas (ie sky)
  • 384x288
  • Uses only slightly more CPU time than 320 x 240 (capture and playback)
  • Fast to post-encode
  • Produces the second smallest filesizes (when using QB encoding)
  • Retains more detail than 320 x 240
  • Keeping in this resolution will result in no resizing artefacts as it's in 4:3 aspect ratio.
  • Still results in loss of fine detail, but viewing at desktop resolution isn't too bad, compression block artefacts still visible
  • Image looks slightly blurred or soft
  • Slight loss of detail also in high contrast areas (ie sky)
  • 640x480
  • Retains slightly more detail than 384 x 288 (barely)
  • You have the option to generate 25fps or 50fps avi files (due to which filter you choose)
  • Second highest CPU usage for capturing
  • Loss of fine detail only just better than 384 x 288
  • Image still looks slightly blurred or soft
  • Captures maybe interlaced (they are on my Capture card)
  • 768x288
  • Retains lots more fine detail over the previous mentioned frame sizes
  • Increased detail in high contrast areas (ie sky)
  • Capturing is guarantee'd to be NON-interlaced, as you're only capturing one field (1/2 height)
  • Requires only slightly more CPU than 384 x 288, during capturing
  • Filesizes are not that much larger than 384 x 288, when using bicubic resizing.
  • Post-encoding takes longer (due to resizing), or you could leave it in 768 x 288 size and have the player resize, but this will generate larger files
  • Due to resizing, you will always get resizing artefacts appear in the footage, especially on fine detail, such as lines can turn into staircases.
  • 384x576
  • Retains lots more fine detail, and with the right filter can look as sharp as 768 x 288 capturing.
  • Experimenting with filters you can have this looking equal to 768 x 576 captures
  • Does not require much more cpu time for capturing than 384 x 288 (less than 640 x 480 capturing), equal to 768 x 288, Uses slightly more CPU than 768 x 288 does for playback
  • You have the option to generate 25fps or 50fps avi files (due to which filter you choose)
  • Captures maybe interlaced (they are on my Capture card, but this could be capture card dependant)
  • Requires additional post-encoding time, and depending on which filter you choose can be quite slow
  • You may still get the staircase artefacts when resizing, but the deinterlace smoother filter can help reduce them.
  • Output files are larger than all the framesize comparisons in this test at 384 x 288 and only slightly smaller at 768 x 576.
  • 768x576
  • The possibility of retaining 100% frame image detail, if used with the correct filter
  • Produced slightly smaller filesizes than 384 x 576 at 384 x 288, but larger at 768 x 576
  • There should be no staircase artefacts because there's no need to resize down (unless you goto 384 x 288), but in the tests here, those artefacts were minimal.
  • You have the option to generate 25fps or 50fps avi files (due to which filter you choose)
  • Captures maybe interlaced (they are on my Capture card, but this could be capture card dependant)
  • Uses massive amounts of CPU time for capturing AND playback
  • 25 FPS
  • Creating 25fps files means faster post-processing
  • Uses less cpu time during playback
  • Creates smaller files
  • You actually lose detail (not frame detail, but motion detail), as only 50% of the frames are captured (when using interlaced resolutions or source footage)
  • 50 FPS
  • Creating 50fps files means all motion detail remains intact, so footage appears very smooth and fluid.
  • I would only recommend creating 50fps files if your source footage (capture resolution) is interlaced.
  • Creating 50fps files means slower post-processing
  • Requires the use of additional filters and programs like AVIsynth.
  • Generates larger files
  • Requires more CPU usage during playback

  • If you wish to see the quality difference between each capturing method, then click on any links below or use the top menu

    Compare 384 x 288 frame image quality Compare 768 x 576 frame image quality


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

    This Page was
    Created on: 3rd August 2oo3
    Last Updated on: 19th September 2oo4

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