HuffYUV & VirtualDub Q:

[IvanP]

Some things are not clear to me.
Everybody is looking for the best method for capturing analog, mainly VHS or Video8.
I'm using HuffYUV. But I don't know what is better. YUY2 or RGB24. All compression are lossless while not converting RGB to YUY2 before compression.
I'm not sure if:
1. VirtualDub operates in RGB.
2. Is YUY2 decompression to RGB lossless? (I know that opposite RGB->YUY2 is not). If VDub internally uses RGB this decompression is neccesary.
3. Is the video stream compressed/decompressed in the video filter chain (after each filter) or decompressed on the beggining and compressed only while saving an avi?
4. I conclude it's better to save result in HuffYUV RGB to avoid the RGB->YUY2 lossy compression. Is it right?
5. What is the native Marvel's video format?
RGB or YUY2?

Disk space doesn't play the role. From the answers I'll conclude if capture RGB or YUY2. Resulting avi's are encoded as VCD later (VHS/Video8 tapes).

Thanks in advance

Ivan

[Dr Mordrid]

The Marvels native format is YUY2. RGB is obtained mathematically from the YUY2 stream, thus making YUY2 the "tree" from which you want to obtain your uncompressed "apple". HuffYUV encodes this data to about half the original size. Huffman encoding is essentially lossless as no DCD encoding or quantization occurs.

IF MSPro/Premiere has a properly set up project profile nothing gets compressed until you render the file and even then you have the option to render to an uncompressed *.avi.

Filter, overlay and effects applications are handled much better with uncompressed video. Since no DCT encoding or quantization occurs the results are cleaner and almost artifact free. It's also much better for encoding to MPEG or streaming formats.

Dr. Mordrid


[This message has been edited by Dr Mordrid (edited 26 September 2000).]

[IvanP]

Thanks Doc, I'll summarize it

Marvel captures YUY2 and passes to HuffYUV
1, HuffYUV compress YUY2 lossless to avi
2, VirtualDUB reads avi that are decompressed by HuffYUV to RGB (I don't know if this opperation is lossless)
3, VirtualDub passes RGB video stream to filter1, filter2, ... (Full processing mode)
4, Save avi uses Video/Compressions presets (HuffYUV for me, the same method choosen for YUY2 and RGB) and passes the RGB video stream (output from the last filter in the chain) to HuffYUV to compress RGB lossless.

please correct me if I'm wrong.

More questions:
What is the best "food" for MPEG encoders YUY2 or RGB? Does it decode everything to RGB before passing to DCT? Maybe all codecs are responsible to provide RGB data stream if they'r asked for. I thing so.

Ivan

[This message has been edited by IvanP (edited 27 September 2000).]

[Eric VanHeest]

I'm pretty sure you can convert from a YUY source to and from RGB all day and not lose anything very noticable (I am not sure about an RGB source, but RGB source is fairly rare unless you are using completely computer-generated video). I'm very certain that RGB lossless compression is considerably worse (in terms of filesize) than YUY lossless.

[Grigory]

Ivan,

Most videocapture cards work in YUV color space, because the videosignal itself has one brightness channel and two color difference channel, transmitted simultaneously. The hardware simple uses these channels as is, producing digital YUV data stream.
That stream can be converted to RGB for
a) displaying a picture on monitor, because it works with RGB
b) utilize filters that were designed to work with RGB.

However, because of the nature of the video, the internal data format in all compression schemes is YUV. MJPEG uses YUV data with 4:2:2 (YUY2 is only code that is used for one possible way of YUV 4:2:2 data packing) sampling, DV uses 4:2:0 or 4:1:1 sampling, mpeg uses 4:2:0.

If you feed video to mpeg compressor, it is always better (and faster) to provide it with YUV data, because the compressor will not waste CPU time for RGB to YUV conversion. Some codecs can output YUV instead of RGB, in this case the compression goes slightly faster. Another codecs, even those that use YUV format internally, support only RGB output.

Mpeg compression compresses Y (brightness) and two (U and V) chroma "images" for each frame.

The last notice: all videocards can do YUV to RGB conversion in hardware, so typically the codec sends yuy2 stream for display adapter too. Every fast decoder now has to work that way because of speed requirements.

Grigory

YUV to RGB conversion is a formula. Because everything is done in integers the rounding errors occur. However, with correct implementation of YUV-RGB formula you probably cannot detect the quality difference for 4-5 generations.

[Dr Mordrid]

Well stated Grigory.

The uppance is to use YUY2/YUV whenever you want the highest quality or plan on encoding to MPEG or other streaming formats. This gives the highest quality, is losslessly compressable using HuffYUV and requires much less in the way of drive subsystem performance to capture. All good things.

Since capturing uncompressed video of any stripe produces large files AVI_IO is indispensable.

Between you, me and the wall I wish Matrox would just drop RGB from PC-VCR entirely and put in YUY2 support instead. A compression tab in there would also be nice

Dr. Mordrid


[This message has been edited by Dr Mordrid (edited 29 September 2000).]

[IvanP]

Thank you all but,

I'm not sure what is encoded to resulting avi in VirtualDub (or Premiere) when using HuffYUV codec: RGB or YUY2?
As I've said I capture YUY2, but filters (delace, resize) works with RGB => I suppose that RGB is passed from ouput to codec.
Resulting avi is RGB compressed by HuffYUV codec. Files are bigger in comparison with the same YUY2 and encoder has to make transformation to YUY2 before entering to DCT.

Q:
How can I force VirtualDub or Premiere to feed the codec directly with YUY2? Or how can I check if RGB or YUY2 is compressed in HuffYUV avi file?

Ivan