Huffyuv Compression ?

[acrubbo]

Happy New Year o Everybody !

I have been capturing video from DirecTv and I´m a little confuse about Bt878 x CX23881 Huffyuv compression.

DirecTv (NTSC)
VirtualVcr
Huffyuv (Predict Left)
YUY2
Audio 44.1 Stereo
720 x 480 x 29.97

Scenary 1

Cable - S-Video
Capture Card - PixelView PlayTV Pro - Conexant Bt878 chipset
Driver - BTWinCap
Compression Huffyuv about 3.0 - 23 GB/h.

Scenary 2
Cable - Composite Video
Capture Card - PixelView PlayTV HD - Chipset: Conexant CX23881
Driver - Version 2.0
Compression Huffyuv about 3.0 - 23 GB/h. the same as Bt878

Scenary 3
Cable - S-Video
Capture Card - PixelView PlayTV HD - Chipset: Conexant CX23881
Driver - Version 2.0
Compression Huffyuv about 1.8 - 43 GB/h.

Anybody knows what´s going on ?


Antonio Carlos

[2ZOD.COM]

The compression ratio depends heavily on what you're watching. Maybe if you tried capturing the same scene from a DVD and there is still quite a difference between the 2 chipsets you can figure that it is the chipset itself causing the problem.

Different chipsets will also have slight differences in the way the color is determined, but that shouldn't account for such a huge change.

[trevlac]

As ZOD said....

I believe huffyuv basically 'predicts' the number of occurences of given pixel values in a frame. Frequently occuring values are then replaced by a 'shorter' symbol. Then a symbol translation table is added for decoding. This would tell you that source with more variation could not be compressed as well.

All of this is an educated guess on how it works, but I'd say it's right in a simple explination.

As I recall, average numbers I've seen for huffyuv are in the 2.3:1 range. So It looks like one of your samples is below average and the others are better. You have to use the exact same source to compare.

[acrubbo]

Thanks for the Reply

More test

My Configuration
ASUS A7V8X
AMD 2600
256 MB
PixelView PlayTV Pro (B878)
PixelView Play HD (CX23881) - 10 bits A/D resolution


The Table shows the end size of AVI files

Source - 007 Die Another Day (DVD) - 1 minute
720 x 480
YUV2

-----------------------------------------------------
|.(Compression )...|CX23881|CX-23881|BT-878.|
|.........................|SVideo...|(Compos |S-Video|
-----------------------------------------------------
|Ucompressed ......|1228 MB|1228 MB |1228 MB|
|Predict Gradient...|1180 MB|0461 MB |0485 MB|
|Predict Mediam....|0890 MB|0439 MB |0448 MB|
|Predict Left ........|0748 MB|0483 MB |0489 MB|
|PICVIDEO Q 20 ..|0520 MB|0463 MB |0467 MB|
--------------------------------------------------------


Why the big different compression between ?

CX23881 (s-video) x CX23881 (composite)
CX23881 (S-Video) x BT878 (S-Video)
CX23881 (S-Video) Predict Left (the best compression) X PicVideo Q-20

Is the b878 giving me a fake frame size (720 x 480) and that affects my compression?


What does the Huffyuv´s expert think about ?


Antonio Carlos

[2ZOD.COM]

If what trevlac said is true (Which I believe is) then the results you're seeing I would guess are normal.

The different chipsets decode color differently, so if one chipset things a certain pixel should be one color and another chipset thinks that same pixel should be another color, then HuffyUV will encode them differently. It would be up to you to decide which chipset is properly decoding it.

You must also make sure that it's EXACTLY the same scene in your test clip. I would say even if you were timing it very well there would still be a 1-3% margin of fluctuation on the file size just because the bits of timing offset.

Basically, the chipsets work differently. Try taking individual frames out of the same clip you've captured with both chipsets and if one's better than the other use that one. Or if you're running low on hard drive space, use the one with better compression.

That's just my 2 cents though.

[trevlac]

"What does the Huffyuv´s expert think about ?"

I hope that's not me. :p I don't even use huffyuv.

My next guess (assuming the source is the same) is that you get more resolution from the s-video on the CX than the BT. More resolution means more detail means more differences. The CX has to do some filtering to get the color out of the composite. Depending on what your driver does, the s-video may not filter as much. The BT does filter NTSC at 6MHz. There may be more involved depending on what the drive does, and what the card has on it, before the signal gets to the chip.

As ZOD said, look at some frames. I'd expect the CX s-video to be a better picture.

This of course does not mean with CATV source you are capturing more info with the CX. The extra stuff may be noise. I have a CX card (MSI), and a BT card (Aver). For CATV captures, use my Aver because the Philips tuner does a better job with the noise. The picture is softer, but does not require much post cleaning.

As for satellite source, beats me. I would not expect much of a difference. You might get a different signal from the composite than the s-video, but I'd think the BT grabs as much resolution as there is. And I would not expect noise for the CX.

Maybe I sould get satellite so I can test. :D

edit
Is the b878 giving me a fake frame size (720 x 480) and that affects my compression?

No fake frame size. You can even go up to 754x480 using the BTwincap driver. That should be bigger.

[angerjas]

|..................|SVideo...|(Compos |S-Video|
|Predict Gradient..|1180 MB |0461 MB |0485 MB|
|Predict Mediam....|0890 MB |0439 MB |0448 MB|
|Predict Left .....|0748 MB |0483 MB |0489 MB|

If "Predict Left" is better than "Predict Median" then
there is probably lot of noise (this also explains low
compressibility - noise is not compressible). For noisy source,
even better than "Left" would be "Predict average of left and
upper" (missing in huffyuv). "Predict Gradient" predicts
U(upper) + L(left) -UL(upper left), so that the compressed
pixel value will be R(residual)=C(current)-U-L+UL.
Assuming that the noise level (stdev) of the original pixels is N,
R will have quadruple variance and double stdev 2N.
If gain obtained by better prediction (taking into account the
gradient) is overweighted by increased noise, "Predict Left" will
be better than "Predict Gradient". "Predict Median" tries to
switch intelligently between "Predict Gradient", "Predict Left"
and "Predict Upper".

BTW using Photoshop, it can be easily visualized what is going to
be compressed. Open file in VirtualDub, copy a frame (Ctrl-1), paste
into Photoshop. Duplicate the layer and apply "custom filter" using
the following matrices (only the central cell and its left-upper
neighbours are indicated here) to obtain predictions:
"Left" "Gradient" "Upper" "Average"
__0 0____-1 1_______0 1_______0 1
__1 0_____1 0_______0 0_______1 0
Further, for the blending mode select "difference". Merge layers
(or "copy merged") and study the histogram, observe the pattern
visually (you may apply "adjust levels" to that end) or try
compressibility by saving uncompressed and zip-ing the file.
In order to create the "Median" layer, first create "Left", "gradient"
and "Upper" layers. Assuming "Upper" is the topmost layer, select
"enlighten" for its blending mode and hide all the layers except for
"Upper" and "Left"; perform "copy merged" and paste as a new layer.
Do the same with "Upper" and "gradient". Blend the two new
layers with "darken" and name the copy-merged result as "Median".