Powered by
To choose the correct capture format I carried out an analysis of the signal and some tests. VCD format is 352x288 (PAL) but should the capture resolution be higher, knowing that further filtering and interpolations will just degrade the picture.
If the source is of quality broadcast (TV for example), the maximum resolution of the video signal will be 768x576 (PAL) and in this case it's better to get the maximum from the capture system (your PC and its PCTV adapter).
In case of personal movies, the definition is also limited by the camcorder or the video tape recorder. Indeed the camcorder records the image by a CCD which current resolutions go from 320,000 to 495,000 pixels in a useful 756x581 matrix. Encoding three colors, the resolution will be divided by 3, or 2 thanks to correlation. In addition the video tape recorder involves a limitation even more significant due to tape properties.
I gathered the most current formats in the following table:
| Format (PAL) | Points by line | Number of lines |
| Broadcast | 768 | 576 |
| VHS | 250 (210 to 280) | 240 (280 for VHS-HQ) |
| S-VHS | 400 | 400 |
| Video8 | 250 | 240 (280 for Sony Video8-XR) |
| Hi8 | 400 | 400 (480 for Sony Hi8-XR) |
In case of family movies, generally - and my own case - the source is a Hi8
camcorder whose signal S-VHS is coded out of PAL CCIR 601 625/50.
The related digital format - that one we'll find at PCTV output - is 768x576
(in fact 704x576, 720x576 or 768x576).
We can say that the horizontal resolution of our PCTV is 768 at most.
From the 625 lines, some are used for synchronization and there remain 576 useful interlaced lines (thus with a temporal shift - which becomes space shit due to motion) that is to say finally 288 useful synchronous lines. I think that if we superimpose the even and odd lines which are shifted in time and we calculate an average (blend) between the two to eliminate interlacing, we obtain some inaccurate picture. It's better to work with 288 synchronous correct lines rather than 288 correct lines and 288 interpolated lines.
Usual coding YUV2 4:2:2 is 704 (or 768) columns for luminance
and 352 (or 384) lines for chrominance. So it seems that the format 352x288
is a very good format which carries most of the useful information.
Nevertheless, if we want to take benefit from the maximum capacity of our PCTV, we may tune our capture system according to his power from 352 to 768 X 288 .
For my tests, I evaluated visual quality after encoding MPEG-1, which is the best choice for video CD. So I didn't retain MJPEG codec ; I worked with Indeo 5.11 and Huffyuv 2.1.1 knowing that best is Uncompressed when PC power allows it.
To encode MPEG-1, I used TMPGEnc beta 12a which gives better results
that AVI2VCD 1-3-7.
Visually, I noted a difference between 352x288 and 528x288, which means that the TMPGEnc encoder takes into account the additional information . The scaling to 352x288 is probably made at output of encoding, it's very good news. I carried out the tests before knowing the limitation of my Hi8 source at 400 points by lines, so I'll remake series of testing with 400x288 and 440x288, but further.
Visually, the difference between the Indeo and Huffyuv codecs are in large uniform areas and in the details. In both cases, the quality provided by the Huffyuv codec is the best at equal resolution. The Indeo artifacts are very visible in large uniform areas whereas Huffyuv restores them perfectly and compresses them very well thanks to its statistical Huffman coding. The Indeo artifacts, which are small squares, can make disappear some details. These observations aren't surprising because Huffyuv is a codec known as lossless (without loss of quality) because it restores the image pixel for pixel as would do a compression in a Zip file.
However, the compression ratio with Indeo is so higher (4x) that sometimes it will allow a higher resolution and in fine, Indeo could restore more details than Huffyuv . For example in the case of a movie with lot of details and without large uniform areas, Indeo 528x288 (883KB/s) will give better visual results that Huffyuv 352x288 (3371KB/s) for a bandwidth much lower. And long movies coded with Indeo will be much easier to handle with video editing software.
I gave a name to the formats: IQ for Indeo Quality and
HLD for High Detail Level. For IQ, the
codec is Indeo 5.11 Quality=100 Key=1 (Key every frame )
and for HLD, the codec is Huffyuv (Fastest).
For all resolutions, the number of lines is 288 ; so I mention horizontal resolution
only if different from 352 (IQ is 352x288, HLD528 is
528x288).
For the Hi8 video, it seems that format HLD480 is quite suitable.
Table to help choosing the suitable capture format:
| IQ = Indeo Quality, adjustments Indeo 5.11 Q=100 K=1 | ||
| IQ | 352 X 288 | Format for standard scenes. |
| IQhhh | hhh X 288 | For long scenes but requiring more details. |
| IQ440 | 480 X 288 | For a Hi8 source. |
| HLD = High Detail Level, adjustments Huffyuv 2.1.1 (Fastest) | ||
| HLD | 352 X 288 | For standard scenes but with Indeo artifacts too much visible. |
| HLDhhh | hhh X 288 | For maximum details (short scenes or very powerful system) |
| HLD440 | 480 X 288 | For a Hi8 source. |
The clip "Original dance Another One Bites The Dust (Queen)"
is 1 minute long. The audio capture is activated but I didn't report audio data.
I used VirtualDUB on a PIII with 933MHz :
| CPU usage | Video size | Rate | Video rate | Compression | Drop / 1500 | |
| IQ | 28-80% | 32MB | 25fps | 549K/s | 9:1 | 0 |
| IQ528 | 60-90% | 52MB | 25fps | 883K/s | 8,4:1 | 0 |
| IQ616 | 60-90% | 59MB | 25fps | 1008K/s | 8,6:1 | 0 |
| HLD | 70-90% | 121MB | 25fps | 2069K/s | 2,4:1 | 0 |
| HLD528 | 100% | 196MB | 24,9fps | 3371K/s | 2,2:1 | 3 |
| HLD616 | 100% | 198MB | 23,5fps | 3584K/s | 2,3:1 | 86 |
Web pages:
Books (in French):
Back to home page
Version of the document: 1.1EN
Created: January 18 - 2001
Updated: February 7 - 2001
Author: Leon