ffdshow huffyuv vs huffyuv 2.1.1

[smok3]

the input was uncompresed avi in RGB24, compressed with ffdshow huffyuv i get (version 3.mar 05)
75 megs
with huffyuv 2.1.1 i get (thats the one in gordianknot codec pack.)
124 megs
(the material is of CG nature...)

whats up with that?

tia

p.s. ffdshow huff wins over lagarian and over corepng as well, hmm, some sort of bug or... ?

-----

p.s.2. redirecting to a proper thread (which i cant find) will be just fine.

[foxyshadis]

ffdshow is almost as fast as huffy, which is twice as fast as lagarith, while being within +-10% of lag's size. It's not a bug, it's just the best thing to ever happen to lossless intermediate encoding. =D

I think the adaptive huffman tables and native yv12 have a lot to do with why it's so efficient. What colorspace did each of your inputs get converted to?

[smok3]

and i guess this version is the same as the one in mencoder?

What colorspace did each of your inputs get converted to?
will check that tommorow with avisynth info function.

[smok3]

more tests, different findings:

original = rgb24, size = 309
ffdshow huf = yv12, size = 75
huf 2.1.1 (default settings) = rgb32, size = 124
huf 2.1.1 (convert to yuv) = yuv2, size = 74
lagarith (default settings) = rgb32, size = 93
lagarith (yv12) = yv12, size = 46
png (default settings) = rgb32, size = 101
png (best compression) = rgb32, size = 96

(i have used vdub 1.6.11 with option full recompress, so i guess that gives rgb32 for codec input?)

notes:
- now this new test gives a different picture than my yesterdays findings (see how 'huf 2.1.1' beats 'ffdshow huf' now...), seems like conversion to yv12 is the best thing to do before encoding?

- lagarith seems unstable, weird frame errors reporting when used via virtualdub

- png is just to damn slow anyway ('best' will give me like 1fps on pentium4 3.2)

(feel free to denie this amateurish findings with some proper arguments.)

---

edit: nm, i just realized i could only compare yv24 vs rgb24 since yv12 is like 4:2:0 only and also that yuv2 (4:2:2) is smaller than rgb24.

edit2: stupidities are greyed out.

[JimiK]

I've never used codecs for lossless encoding. But some things I find rather intriguing:
First of all, encoding to yv12 or yuv2 is not lossless, because they subsample chrominance. So you lose some information on the color of a pixel.
Second: is there no option to encode to rgb24 in all these codecs? Encoding to rgb32 does not make sense when the source is rgb24. Furtherm, the additional 8 bit in rgb32 are used for the alpha channel that stores a transparency value. I see this as quite useless in video encoding, so I wonder why these codecs implement that. Maybe someone can help me/us out with that.

[smok3]

afaik rgb32 is easier to handle programing wise (i read that somewhere....)

why do you think alpha channel is useless?

(btw, they all support either rgb24 or rgb32, except i can't find such option in ffdshow.)

question: what would a proper command line for mencoder to get rgb32 huff encode with audio? (where input is uncompressed avi with uncompressed audio)

[Zarxrax]

I've never used codecs for lossless encoding. But some things I find rather intriguing:
First of all, encoding to yv12 or yuv2 is not lossless, because they subsample chrominance. So you lose some information on the color of a pixel.
Second: is there no option to encode to rgb24 in all these codecs? Encoding to rgb32 does not make sense when the source is rgb24. Furtherm, the additional 8 bit in rgb32 are used for the alpha channel that stores a transparency value. I see this as quite useless in video encoding, so I wonder why these codecs implement that. Maybe someone can help me/us out with that.

First of all, most people are encoding DVD sources, which are ALREADY YV12. Thus you are not losing any data when you compress them to YV12 in a lossless codec. In fact, if you convert them to RGB then you would most likely be losing some quality!

As for RGB24 vs RGB32, RGB32 does not take up any additional space as opposed to RGB24. Why not? Because nothing is being stored there! So why use RGB32? Because 32 is a good number for computers, and the data can be processed much faster than in an RGB24 file.

And as for alpha channels, they are far from useless. I use them all the time.

[mpucoder]

First of all, most people are encoding DVD sources, which are ALREADY YV12.
If I understand YV12 correctly it uses only 8 bits for each of the color elements, right? DVD, which is mpeg-2, uses 9-bit accuracy for the YUV elements. See Annex A of ISO/IEC 13818-2, which states:
The input to the forward transform and the output of the inverse transform is represented with 9 bits.
Encoders working from RGB are expected to do the colorspace conversion with 9 bit accuracy as well.

[GodofaGap]

All decoders output 8-bit, so it does not matter what is used internally. There are no 9-bit colorspaces available that I know of.

[mpucoder]

Not all decoders, but probably all PC decoders as that's the limit of the graphics cards.
But the real question: Will a YV12 source produce a different encode than the original RGB? And the answer is yes, because of the loss of precision in the YV12 conversion. And that leads to further differences in the decode. So if you are asking if YV12 preserves all the essential data, it does not.

[GodofaGap]

Not all decoders, but probably all PC decoders as that's the limit of the graphics cards.
But the real question: Will a YV12 source produce a different encode than the original RGB?
Encoding with what? A lossless encoder? Yes certainly. MPEG2 using 4:2:0 color sampling? Assuming the subsampling done is identical I doubt it. RGB is still 8 bit, the difference is only in the *resolution* of the chroma.

It would make for a nice experiment if the subsampling issue can be avoided though. :)

[foxyshadis]

RGB and YUV are so different that simply comparing their bitdepths is incorrect. RGB cannot be entirely losslessly preserved without 12-bit YUV, iirc, even that may clip chroma in the top and bottom of the luma range. 10-bit is enough to eliminate visual banding though.

[WorBry]

Being one of those poor souls (I'm sure I'm not alone) who has expended many long hours archiving deinterlaced (mvbob and/or EEDI2-TDeint) DV footage in YUY2 format (HuffYuv 2.1.1 and more recently MSU LVC 0.60), it has finally dawned that YV12 is a better a better way to go, in terms of both AVISynth processing speed (i.e. deinterlacing and denoising) and final file size (compressibility).

Although the 'final destination' progressive formats that I currently use (primarily DivX and XviD) are YV12, I originally chose to archive in YUY2 just in case some future 'super codec' is developed based on YUY2 or for which YUY2 is the preferred input. From a theoretical viewpoint, is this ever likely or am I reasonably safe in commiting my progessive archives to YV12? I do archive my original (edited) DV footage as a fail-safe, but would prefer not to have to deinterlace again if avoidable.

My second query is - what are the recommended settings for FFDShow HuffYuv in YV12? I know that use of the 'adaptive Huffman tables' is beneficial, but am not sure which predictor to use - Plane (default), Median or Left, and what FourCC should I use - HFYU or FFVH? Finally, is the stability of FFDShow HuffYuv such that I will not face incompatability problems decoding my archives with future builds?

Thanks.

[GodofaGap]

DV footage is 4:1:1 for NTSC and 4:2:0 for PAL, storing that as YUY2 is hardly benificial. :) (maybe for NTSC it makes sense, as I don't know lossless codecs that do 4:1:1, but since you keep the DV tapes...)

The best way to keep compatible with ffdshow, is backing up a copy of the ffdshow version you used too.

[foxyshadis]

ffdshow huffyuv is always going to be compatible with itself, it's not a wide gap from huffy. However, ffv1 changes and breaks practically every release, so it's the worst archive format. That's the one you should be very worried about using.

[Tommy Carrot]

ffdshow huffyuv is always going to be compatible with itself, it's not a wide gap from huffy. However, ffv1 changes and breaks practically every release, so it's the worst archive format. That's the one you should be very worried about using.Actually ffv1 has not been changed for more than a year and the bitstream will probably be frozen quite soon (http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/008379.html).

[WorBry]

DV footage is 4:1:1 for NTSC and 4:2:0 for PAL, storing that as YUY2 is hardly benificial. :)

I realize that now. Thinking back, my misconception about YUY2 arose from reading articles several years back which held HuffYuv to be the most stable of the available lossless codec. At that time the few codecs that could output YV12 were few and experimental.

I've now radically changed my workflow for processing native PAL DV to progessive footage (archived) to MPEG4, staying in YV12 throughout. I was previously using the Sony DV codec, which outputs RGB and requires correction of a luma shift after conversion to YUV. I've now switched to the Cedocida v0.1.6 codec which, although slightly less compressible, can output YV12 and maps the luma correctly. Like the Sony codec (and Matrox DV codec) it also avoids the saturated 'chroma bleed' that I was noticing with other DV codecs; maybe this is not an issue for those people with 3CCD camcorders, but it was with my Sony DCR-PC115E with single (HAD) CCD.

I'll play around some more with the other available 'lossless' YV12 codecs, but from my preliminary results I'm quite happy with FFDShow HuffYuv on balance of encoding/decoding rates vs file size, and the quality of 'HuffYuv to DivX encodes', both visually and in terms of video quality metrics (so far just PSNR and DRF's).

However, as requested above, I would appreciate some advice on the optimal HuffYuv settings. I've assumed 'median' for the Predictor setting, simply because this is what is stated for HuffYuv 2.1.1. Is this correct? Also, what FourCC should I use, if that actually matters?

Thanks.

[GodofaGap]

FOURCC has nothing to do with the compression at all. And well, you can always change it afterwards...

As for the better predictor setting: I don't know. I suppose you could run some small (say 10,000 frame) tests.

[smok3]

WorBry: whats the purpose of turning DV into huff? (or any lossless format?)

[WorBry]

In my case, purely for archiving footage in a deinterlaced (progressive), denoised state to serve as a 'master' for conversion to other working (lossy) formats, both current (principally DivX 6) and developmental.

I’ll explain. Although MVBob, and other AVISynth 'motion-compensated/smart-bob' deinterlacers (EEDI2-TDeint, SecureDeint), produce amazing results, they are slow and when denoisers are added to the process (I prefer Convolution3D and RemoveGrain for my DV sources), I'm looking at 28-30mins to render 1min of 50fps footage on my AMD 2800XP. I then convert the 50fps output to 25fps with motion blur. This is not so much to achieve a 'cine effect' as to preserve the fluidity of motion; in my experience, a straight decimation (SelectEven) of the 50fps footage leaves a slight juddering. Internal over-sampling with a temporal-blur helps to smooth this out more effectively than blending, which tends to produce ghosting. For this purpose I am using a modification of Scharfis_Brain's mvfpsscd function (originally based on MVConvertFPS from MVTools) replacing MVConvertFPS with MotionProtectedFPS (from MG32 Clouded's 'Motion' package). This conversion is likewise quite slow (7-8 mins per min of footage) and CPU intensive. Arduous you might say, but the end results are worth the wait.

Thus, my need for a good lossless codec arises for creating both the 50p intermediate and the final 25p archive. For the first (DV to 50p) step I was originally using the Sony DV codec which outputs RGB, and converting this to YUY2 (with a correction for the luma shift that occurs with this codec, to preserve TV scale). MVBob, Conv3D and RG, all handle YUY2 so I was using HuffYuv 2.11 to create my intermediate 50fps footage. However, for the second stage, it was necessary to convert to YV12 for the MotionProtectedFPS function (which does not accept YUY2). My mistake was then using HuffYuv 2.11 again for the final archive. Thus, the footage underwent multiple color-space conversions by the end of the process.

DV (YV12) → RGB → YUY2 →YV12 →YUY2 (archive) → working format e.g. MPEG-4 (YV12)

So, now I’ve changed to a ‘total YV12’ process using the Cedocida DV decoder, a YV12-compatible version of Convolution3D and am evaluating the YV12 ‘lossless’ codec options for the intermediate and archived footage.

[smok3]

ic, quite a 'pipeline' you have there, i guess i should be happy that my DV can record progresive (and i do record progresive 99.9% of the time.)

interesting read, tnx for sharing.

[Boulder]

Just remember that the YV12-compatible Convolution3D isn't 100% working. The temporal influence (the same as scenechange detection?) parameter isn't respected. I think Deen with the default c3d mode is pretty much the same as Convolution3D, you probably just need to lower the thresholds a bit.

[WorBry]

Smok3

Yes it is quite tedious, but it keeps me out of mischief :) Also for PC playback (with my new Philips 19'' LCD monitor....that's where the money went) I much prefer the look of progressive video than DV or DVD deinterlaced 'on the fly'.

Boulder

Thanks for the advice on Conv3DYV12. I'll have a look at Deen. I also experimented a bit with FFT3D but was getting some block artifacts with my DV sources. Also very slow.

If your interested, here are the two AVS scripts that I'm using currently (with Cedocida and FFDShow HuffYuv YV12).

avisource("C:\Pal DV type II.avi")
interp = separatefields().eedi2(field=2)
tdeint(mode=1,order=0,edeint=interp)
LanczosResize(720,544)
Convolution3D(1,4,5,3,4,2.8,0)
RemoveGrain(mode=2)

and then:

avisource("C:\50fps intermediate.avi")
mpfpsscd(25,oversample=16,blurradius=4)
#
function mpfpsscd(clip i, float fps, int "oversample", int "blurradius")
{
oversample=default(oversample,1)
blurradius=default(blurradius,1)
mv=i.MotionProtectedFPS(fps*oversample,warpfast)
global mv= (oversample>1) ? mv.temporalsoften(blurradius,255,255,mode=2).selectevery(oversample,0) : mv
global ch=i.changefps(fps) #. subtitle("ch")

global msk0=ch.duplicateframe(0).reduceby2().reduceby2().motionmask(thsd=255,y=3,u=1,v=1)
global msk1=msk0.trim(1,0)
global msk2=msk0.trim(2,0)
global msk3=msk0.trim(3,0)

f0=scriptclip(ch,"""sc""") #.subtitle(string(a0)+" "+string(a1)+" "+string(a2))""")
f1=f0.frameevaluate("""sc= (sc2 || sc1) ? ch : mv""")
f2=f1.frameevaluate("""sc2=( (a2 > (a1*5+25)) && (a2 > (a3*5+25)) ) ? true : false""")
f3=f2.frameevaluate("""sc1=( (a1 > (a0*5+25)) && (a1 > (a2*5+25)) ) ? true : false""")
f4=f3.frameevaluate("a3=averageluma(msk3)")
f5=f4.frameevaluate("a2=averageluma(msk2)")
f6=f5.frameevaluate("a1=averageluma(msk1)")
f6.frameevaluate("a0=averageluma(msk0)")
}


function MotionProtectedFPS(
\ clip input, float FPS,
\ int "mode", int "protection",
\ int "iterate", int "reset", int "initialise")
{
mode = default(mode, warpfast)
protection = default(protection, 80)
iterate = default(iterate, 2)
reset = default(reset, 50)
initialise = default(initialise, 6)

originalFPS = input.framerate()
input

mp = FindMotion(iterate = iterate, reset = reset,
\ initialise = initialise)
p = MotionFPS(FPS,mode,Motion = mp)
maskp = mp.SumStretchFPSMask(FPS, protection)

mn = FindMotion(iterate = iterate, reset = reset,
\ initialise = initialise, from = next)
n = MotionFPS(FPS,mode,Motion = mn, source = next)
maskn = mn.SumStretchFPSMask(FPS, protection, source = next)

maskp
assumeFPS(originalFPS)
CombineFPS(FPS, maskp, maskn.Invert())
bilinearresize(width*8, height*8)
crop(0, 0, input.width(), input.height())
fity2uv()

maskedmerge(p, n, last, u=3, v=3)
}

[zilexa]

So what is better? using the separate huffyuv encoder or ffdshow?

[unmei]

since no answer to the predictors question was posted yet, i made a small speed vs size test:

source: 2000 consecutive frames of titeuf cartoon, 720x576, yv12 ffdshow huffyuv (pred=plane), no avisynth processing in this run (to not tamper with speeds)

setup: VDM, fast recompression, athlon xp @ghz, 1gb ram

results:

predictor size (MiByte) enc.time (s)
---------------------------------------------------------
left 410 756
plane 393 772
median 356 756


However this only a single-sample test, in other times it seemed to me "plane" gives a slightly smaller size than "median", at comparable encoding time. But "left" seems consistently to be the mode that results in larger sizes and faster encoding.