Huffyuv for the HD Era: An SMP/Multithreaded Port?

[easy2Bcheesy]

I've been working with high definition video for almost a year now and I'll be honest here - there's not much that can match the performance or compression of the brilliant CineForm HD DirectShow encoder.

Only one codec gets anywhere near the performance level in terms of encoding on the fly and that is... good old Huffyuv. Even a basic 1mb cache 3.0GHz Pentium 530 CPU can encode 720p at 60fps. Indeed, I reckon that with a little bit of tooling (ie multithreading support), Huffyuv could most likely handle 1080p/30.

Filesizes are obviously much larger than CineForm, but why the love for Huffyuv?

1. It reduces HD bandwidth so that even a basic SATA drive can cope with it with zero lost frames
2. It can losslessly handle 4:4:4 or any other HD pixel format I throw at it and offers a quality edge over CineForm - or any HD codec - useful in multigenerational editing
3. Picture quality in HD is simply breathtaking

So the questions I would have are...

1. Is Huffyuv written in a way that would benefit from SMP optimisations?
2. Am I the only person in the world who would find this useful :D
3. Any one willing to give it a shot?

[squid_80]

What about lagarith? It's not much slower for encoding and is meant to be multithreaded already.

[Revgen]

lagarith has a more complicated algorithim and isn't as fast as Huffyuv. It's optimized to compress better at SD resolutions at a normal 30fps speed. Huffyuv isn't optimized for SMP because nobody has needed it until now.

[CruNcher]

Marcfds VBLE test version lg3 is much better in terms of compression factor @ 720p only LocoCodec comes near this yet but don't forget Cineform is visually lossless you can also get LocoCodec in this mode any maybe sooner or later a new VBLE ;) i think it's time for a HD comparsion of the best lossless Codecs vs Cineform HD :P

[easy2Bcheesy]

If people can provide me with download links I will be happy to attempt realtime 720p capture with those compressors. Right now, CineForm is the undisputed king of the lossy compressors (look hard enough and you can see the compression but you REALLY need to look hard enough), but I would still like a mathematically lossless solution.

A multithreaded huffyuv is attractive because not only could it easily handle 720p/60, but enough CPU overhead would be left over for other tasks too.

However, as I said, please let me know what codecs to try and where to get them and I'll be happy to give them a go.

[Revgen]

Loco and VBLE are at: http://forum.doom9.org/showthread.php?s=&threadid=53305

Lagarith is at http://lags.leetcode.net/codec.html

[easy2Bcheesy]

Well the results are thus. I've turned off the Preview Window to provide as much horsepower as possible to the compressors and fed it an Xbox 360 signal running at 720p/59.94. My PC is an Athlon X2 4400 based PC with 2GB of RAM running 32-bit Windows XP.

So any way, results...

CineForm DirectShow (multi-threaded): 59.94fps
Huffyuv (single-threaded): 59.94fps
VBLE (multi-threaded): 52.15fps
CineForm VFW (single-threaded): 49.23fps
Lagarith (multi-threaded): 20.98fps
Loco (single-threaded): 15.58fps

There may be some variance in the exact results as I could not feed the compressors with the exact same video to compress, but I ran the test several times and the results didn't vary THAT much.


Conclusions

1. CineForm HD
It was unfair to include CineForm in this comparison I know, but as a benchmark of the state-of-the-art encoder up against the competition it was interesting to put it up to the same scrutiny as the other codecs. I did run it in max quality mode which has a big impact on its performance compared to lower quality levels. It's a CQ codec and compression varied between 5:1 and 12:1.

2. Huffyuv
God knows how old it is, but my tests confirm that this is still the best codec out there for lossless 4:4:4 capture. Compression is usually around 2:1 to 3:1 and that's fine with me.

3. VBLE
The surprise package in that I reckon on a decent Conroe machine, it'll be able to capture at 720p/59.94 with ease being already multithreaded. However, as the codec is inherently using YV12, the result is definitely not up to the same quality as Huffyuv and as such has little value when you're looking to capture 24-bit RGB losslessly.

And the rest...
I'm sure they have their uses, but it isn't for realtime HD capture. I feel as though I am right back where I started to be honest in that I would kill for an n-way threaded version of Huffyuv.

[dragongodz]

have to tried the huffyuv thats from libavcodec as used in FFDshow ? thats meant to be slightly faster and compress better than the original huffyuv. its not compatible with the old codec of course which is why you can use the fourcc ffvh.

interestingly it doesnt have an option for amount of threads where many others included do. for example flv1 you could set 3 threads and do a constant quant encode and see how that performs etc. of course there is controls such as ME size etc which effect speed and quality.

[easy2Bcheesy]

Huffyuv as it stands in its VFW codec form is a lovely compressor to use in an HD workflow, and while a little bit of extra speed is nice, I need much much more - the kind of speed increase that only multi-threading can provide. I really want a truly lossless codec that will get more powerful as dual and quad core CPUs come out.

CineForm HD will do that as it makes use of all processing paths available (even HT ones on an Extreme Edition 955 Pentium D for example). If I bought a matched pair of 3.46GHz Dempsey CPUs, CineForm would make use of all eight CPU threads that would be available.

But there is no lossless 24-bit RGB equivalent to CineForm HD - another limitation of CineForm is that it's inherently based on 4:2:2 compression and is using CQ lossy compression.

[smok3]

dragongodz, i found no way to force the ffdshow to use anything else than yv12 for compression?, so thats why it compresses better (its not lossless).

[dragongodz]

Huffyuv as it stands in its VFW codec
the compressors in FFDshow are of course also vfw.

while a little bit of extra speed is nice, I need much much more
it would still be interesting to know how much faster it actually is. is it a little or is it substantial ? you would need a clip where normal huffyuv couldnt keep anywhere near framerate to test of course.

i found no way to force the ffdshow to use anything else than yv12 for compression?
the huffyuv in ffdhsow will do yv12 or yuy2, selectable in the generic section.
also in the inout section colourspace input can be forced to many more.

so thats why it compresses better (its not lossless).
hmm my impression was the tests done ages ago on the ffmpeg mailing list was done with the same colourspace and the libavcodec version compressed better and faster since it had been worked on past the final verion of huffyuv.

since we are talking about lossy though yes there would be a colourspace change needed to use the ffdshow version but you woiuld have to test to see if you will notice it or not. also cineform ,which easy2Bcheesy is also testing against, is not lossless. and finally of course for 4:4:4 the colourspace change is needed but for other sources such as dvd/mpeg it would not.

anyway i was simply throwing in some other possible option that may be worth trying.

[foxyshadis]

I was going to suggest FFV1, since it can capture in any colorspace, but testing proves it's slightly slower than lagarith. Shockingly high compression, though, easily the most size-efficient of any lossless I've tried (including AVC). (Unless you use pseudo-lossless xvid, EHR@q2. Which incidentally is about the same speed and 1/3 the size.) Guess it's no good for your purposes, even multithreaded.

Huffyuv on the other hand is shockingly fast indeed. And it's such a brain dead codec that it can't be hard to multithread, especially if there was no requirement to keep the bitstream back-compatible. I can try it, once I finish up a current project, but threading isn't a strong point of mine. ^^;

smok3, ffdshow's (lavc) huffyuv accepts yv12 and yv16 (it converts yuy2 into yv16 first).

cheesy, you have to capture rgb32, and not yv24? Or is that just because huffyuv doesn't support yv24? It'd be easy to adapt lavc's into doing that. Everything output to television is YIQ or YCbCr anyway.

dragongodz, I think the improved compression comes primarily from yv12 support, since the algorithm is essentially the same with minor tweaks.

[easy2Bcheesy]

Yup, no requirement to keep the bitstream back compatible, but just so long as it's fully VFW compliant and the streams will work in Premiere and After Effects etc, that's fine.

I am capturing 24-bit RGB and YUY2 typically.

[Wilbert]

Everything output to television is YIQ or YCbCr anyway.
YIQ is not used anymore by NTSC. NTSC uses the same as PAL, which is YUV (YCbCr is a digital format). Anyway, back on topic :)

[dragongodz]

I think the improved compression comes primarily from yv12 support, since the algorithm is essentially the same with minor tweaks.
from memory its also not compatible with normal huffyuv so i think its a little more than that.

easy2Bcheesy - you can give this a try if you like
http://d.turboupload.com/d/815066/huffyuv-test.zip.html

[easy2Bcheesy]

dragongodz: there's a definite performance increase with your test version of huffyuv. And VirtualDub is reading CPU usage at 172%, so whatever's going on is definitely multithreaded. However, the performance increase doesn't seem to match the increase in CPU usage which is interesting.

Tell me more! :)

[dragongodz]

bit of a quick cheat really. its simply
/Qipo /Qopenmp /QaxKWN /Qparallel

plus libguide.lib linked so it doesnt look for libguide40.dll.

this version i just changed to /QaxKWN to /QxK which should mean use SSE with no checking.
http://d.turboupload.com/d/819233/huffyuv-testSSE.zip.html

[squid_80]

But the real reason huffyuv's so fast is because it's written almost entirely in assembly... The prediction functions could probably be multithreaded fairly easily but I don't know about the encoding functions.

[dragongodz]

i agree to get the most out of it someone would probably have to look at hand threading the asm. i just wanted to see if a quick compiler change plus options would be noticably beneficial.

on that note heres lagarith 1.38(1.39 source is not on the website) with those same first changes. if you could give this a quick try aswell easy2Bcheesy, it would be interesting to see if it gains much over that previous test you did with the normal release.

http://d.turboupload.com/d/819997/Lagarith_138_test.zip.html

[easy2Bcheesy]

Hi,

Great to do some testing!

Bizarrely the SSE huffyuv appears to be a bit slower than the first test version.

VirtualDub, preview window on, 720p/59.94: CPU usage ranges between 75% to 81% on the old version. On the new version it's much the same but with the occasional spike up to 88% CPU usage.

New Lagarith Test: 25.55fps so only a marginal improvement, but I guess it's a massive performance boost for a very simple code tweak.

[Hellworm]

btw ffvhuff compresses better and is not standart huffyuv, because it can use adaptive huffman tables.

[easy2Bcheesy]

But it's not totally lossless 24-bit RGB, is it?

[dragongodz]

New Lagarith Test: 25.55fps so only a marginal improvement, but I guess it's a massive performance boost for a very simple code tweak.
well its an over 20%(of original speed) boost. thats not too bad for a simple compiler change indeed. :)

But it's not totally lossless 24-bit RGB, is it?
looking at the FFmpeg source code it appears for RGB24 and RGB32 it uses normal huffyuv and for YV12 and YUY2 you can use ffvhuff. so i guess really that could be set in FFDshow if Milan wanted to.
but no as i mentione earlier if your source is RGB24 then you need to do a colourspace conversion to either YV12 or YUY2 for FFDshow, which it then compresses lossless. how much do you lose from this conversion really though ? thats something you would have to try for yourself and decide if its worth it.

[easy2Bcheesy]

Lagarith is YV12, I think, and yes, picture quality is good but it is not lossless RGB24 and you can see the difference. If it's not lossless, CineForm rules :) As a straight alternative to capturing uncompressed, Huffyuv is simply superb.

[dragongodz]

but it is not lossless RGB24 and you can see the difference
hmm thats strange, i though Lagarith was for all colourspaces. infact it was written around huffyuv source(which you can easily see in Lagariths source archive) and uses a few of its routines. will have to have a look when i get the chance. pretty busy at the moment though.

EDIT:
Lagarith is YV12, I think,
in its settings you can set the colourspace for it to work in. RGB(RGB24), RGBA(RGB32), YUY2,YV12.

[squid_80]

Lagarith is RGB, YUY2 or YV12. I've used it for capturing YUY2/720x576/25fps with no dropped frames at 60% cpu usage... But that was the 64-bit build, which is out of scope here.

[easy2Bcheesy]

Indeed, Lagarith is way too slow unfortunately :( Faster with YUY2 though, but for any YUY2 capture, CineForm produces astonishing quality and very small filesizes, plus the AVIs drop straight into their Premiere Pro accelerated editing environment.

[squid_80]

Do you have the capabilities to test huffyuv with a 1080p/30fps/RGB24 capture, just to see what framerate it can get?

I hated dealing with huffyuv because it was so complicated, but I'm starting to get interested... Unfortunately I don't have a multi-core machine so I'd be flying blind. But a general huffyuv overhaul would be possible, proper YV12 support (not via ffdshow, which is slower than the original huffyuv) and SSE2 instead of MMX would be a start.

Edit: Also the "predict median" mode for RGB for better compression.

[easy2Bcheesy]

My system is currently optimised for 720p/60 - RGB24 1080P would struggle to top 11 of 12fps in its current form. A proper 1080p digital input is something I'm only really interested in investing money in when I know there's a codec that can handle it. And when I make that hardware leap, I'd really want 1080p/60.

I could certainly simulate 1080p/30 though with a resize filter on the fly though and we could measure the CPU load that induces and weight that against the final results. Alternatively I could hook up my PC and see how it handles an intermidiary resolution such as 1440x900.

[squid_80]

The good news: It's possible to multi-thread both the prediction and encoding functions. At least, I'm using multi-threads on my single cpu machine and it's working.

The bad news: The bitstream's not backwards compatible, and I've got no idea how to make it so.

I'll put some stuff up for testing tomorrow, to find out how it really works on a multi-cpu machine.

[easy2Bcheesy]

Great! Backwards compatibility isn't really a must - the raw speed increase most definitely is :)

I look forwards to testing for you :)

[Revgen]

BTW, Dragongodz, thanks for the Lagarith build. I can now capture in realtime with almost no dropped frames at 720x480 using multithreading.

[foxyshadis]

squid_80: give it the 4cc HFYM or something like that, so it doesn't interfere with normal huffyuv then. The extension to YV12 and MT sounds really cool. =o

[squid_80]

Ok before I get too carried away let's see if multithreading actually helps at all.
http://okejl.dk/dunstan/huffyuv2.zip
That's a slightly modified build of huffyuv with multithreading (2 threads hardcoded) on the YUY2 Median compression method only - the other methods/colorspaces haven't been touched. The 4cc is HFY2, the codec shows up in virtualdub as NEW Huffyuv v2.1.1 and can be uninstalled via control panel->add remove programs without hurting any existing huffyuv installs. This is all because it's a simple test, I wouldn't advise anyone to hang on to it for ongoing use - just try and capture something using yuy2/median, check the speed against capturing in uyvy mode (which is virtually the same but not multithreaded), make sure the file can be re-opened*, and report back.

Sometimes the bottom half can be slightly messed up. This is what happens when the 2nd thread finishes before the first has even started - a very rare case which has only happened to me once. A fix is planned for later.

My tests so far have been sadly non-optimistic. But that's with a hyperthreaded machine, so let's call them inconclusive.

[easy2Bcheesy]

1280x720/59.94 capture from YUY2 source (Xbox 360 dashboard so pretty static with a rolling tint in the background):

Original Huffyuv: CPU usage from 66% to 75%
New Huffyuv: CPU usage is all over the place, starting at 78% and going up to 97%, averaging at 88%

It's difficult to measure in any other way - any transformation filter I invoke requires operating in the RGB domain so by the time it reaches the compressor it's no longer YUY2.

[dragongodz]

easy2Bcheesy - if its not too much trouble can you include one of the builds i did for comparison ?

squid_80 - from what i have seen 3 threads seems to be generally the number for real good gains. thats based off other programs/codes such as Xvid.

[easy2Bcheesy]

hi dragongodz - in terms of CPU usage, the first version of huffyuv you uploaded appears to have extremely similar levels of load as the original huffyuv.

[squid_80]

Without a proper machine to test on I'm really shooting in the dark. It could simply be that the overhead time to create/destroy the threads is longer than the total processing time. If that's the case I might have to do a bit of reworking.

As an aside, huffyuv always assumes any stream with height > 288 is interlaced, and unfolds the fields side by side before compressing. By introducing an interlaced option in the config and turning it off for progressive sources I'm seeing a compression boost of about 10%.

[Sharktooth]

I think inverse hyperthreading will be really usefull... ;)

[easy2Bcheesy]

Heh, is that actually real or just a myth? The facility to have the single-threaded CineForm VFW encoder inversely hyperthreaded would be worth its weight in gold, however, I'm veering more towards 'myth' at the moment. Some things are just too good to be true ;)

[Sharktooth]

it's in the specs of the K8L.

[squid_80]

O RLY? (http://www.reghardware.co.uk/2006/07/17/amd_reverse_ht_not_real/)

[Sharktooth]

O RLY? (http://www.reghardware.co.uk/2006/07/17/amd_reverse_ht_not_real/)
This is the original:
http://www.xbitlabs.com/news/cpu/display/20060714052807.html?www.reghardware.co.uk
However it's all about unreachable/unnamed sources...
And remember AM2 CPUs comes with virtualization (and theoretically it is possible to emulate 1 CPUs with multiple cores - read: inverse hyperthreading).
So, i do not believe a single word from those 2 sites...

[foxyshadis]

The problem is that AMD has to do in hardware what compilers do in software - and compilers are already notoriously bad at automatic multithreading (ie, /Qparallel), even given a holistic view of the entire application and all the time it needs instead of just the current instructions and billionths of a second. </off-topic>

On topic, there isn't any great speedup for me, but then, I can capture 1440x960x60p or 1920x1080x30i in realtime anyway with dragongodz's compile. I get ~50fps on the latter with squid_80's and ~47fps with dragongodz's. (CPU usage wasn't noticeably higher, a little over 50% each run, but that's a red herring anyway; only fps matters.)

[easy2Bcheesy]

What CPU are you using there foxy? If we are moving into the realms of 1080p/60 (as I certainly want to be doing next year) I seriously think we're going to need to go quadcore, or perhaps even dual Woodcrest/Dempsey.

That said, a dual Opteron 275 system can apparently capture 1080p/60 into the n-way threaded CineForm encoder...

[foxyshadis]

Merom. :p The huffyuv compression of 1080p/30 is only ~70% of one core. Any conroe, woodcrest, or recent x2 should have no problem with that part. (Now if you wanted to run some kind of filtering first, along with the bus transfer effects...) Cineform would undoubtedly need all of both cores, but that's why you stack 'em up.

To clarify, as I said in mail to easy, I'm not actually capturing. I tried using both generated noisy video and video captured over GbE through avisynth's tcpdeliver to soft-of simulate capturing.

[squid_80]

I was wondering how you were capturing ~50fps from a 30fps source...

[dragongodz]

I was wondering how you were capturing ~50fps from a 30fps source...
i actually like to see that figure. helps to give a more real view than just cpu percentage usage alone. now if foxyshadis had given the original huffyuv's fps aswell that would have been even better to see how much gain these things(including my simple compiler changes) were giving. ;)

Without a proper machine to test on I'm really shooting in the dark.
my athlon xp 2400+ doesnt exactly allow me to test/see the effectivness of threaded changes either. ;)

EDIT:
squid_80 - out of curiosity what compiler are you using for your compile ?

[easy2Bcheesy]

Merom. :p

Ahhhh Merom... my T7400 can encode difficult 720p material at 84fps with the CineForm encoder :eek: In fact, while I'm at it, here are some official CineForm benchs on the new Intel architecture, all the way from the dual core Merom, to dual next gen Xeons. Shamelessly ripped from CineForm CTO David Newman's Blog (http://cineform.blogspot.com), which is essential reading if you're working day to day with HD

http://img221.imageshack.us/img221/4246/untitled1uf1.jpg

I'd expect encoding performance to match Decoder 3 scores (that's CineForm's n-way threaded reference quality decompressor). Decoder 2 is the slightly less optimal playback decoder for Media Player/Premiere Pro etc.

By way of reference, my Athlon X2 4400 desktop system achieves a score of 69fps using the same benchmark tool (also how I double-checked my Merom performance). Suffice to say, my next desktop system will most likely be based on the quad core 2.66GHz Kentsfield (engineering samples available now if you know where to look - a snip at $1700!!!)

If it gets midway performance between the Conroe and Woodcrest scores, that should be more than sufficient for 1080p/60 capture.

[squid_80]

squid_80 - out of curiosity what compiler are you using for your compile ?
At the moment using VS2003. I have ICL 9.0 and VS2005, just haven't bothered trying them until I get everything working properly (the YV12 stuff is being stubborn and refusing to work).
Most of the heavy code is in the .asm file (except, curiously, the rgb->yuy2 routine), I'm surprised it makes much difference which compiler is used unless it's doing some sort of whole program optimization.

Anyone know of an easy way to generate some default huffman tables for the rgb/median method? I'm thinking an avisynth plugin would probably be easiest, and I can adapt it to create "best fit" tables for any source. It sounds good, but I don't know how practical it would actually be.

[dragongodz]

I'm surprised it makes much difference which compiler is used unless it's doing some sort of whole program optimization.
of course it shouldnt make a huge impact, with as you say most of the heavy stuff in asm, but it can still have some impact optimising everything else. yes the intel compiler is meant to optimise better than the ms compiler. it may only be a few extra fps squeezed out but it can still be worth it for the tiny amount of effort it takes.
not saying its worth much in this case, thats why i said it would have been interesting to see foxyshadis compare to original huffyuv aswell, to actually see what was gained.

[foxyshadis]

Arrr, ye rogue, ye did wrung it out of me. Rough timings:

1920x1080, median
Huffyuv 2.1.1: 46 fps.
Dragongodz: 47 fps.
Squid_80: 50 fps.
- predict left is about 40% higher in all.

1440x960:
Huffyuv 2.1.1: 64 fps
Dragongodz: 69 fps
Squid_80: 74 fps

[squid_80]

Made some progress on YV12 support: http://okejl.dk/dunstan/huffyuv.zip

Changed back to using the original 4CC, shouldn't do any harm - files incompatible with the older version should pop up an error, rather than trying to open something they can't. Turning the interlaced content option off always seems to give better compression in my tests. When opening a YV12 compressed file, virtualdub complains about not finding a compatible target format but once the file is played a bit everything works.
Ignore the blank spinbox in the config, it doesn't do anything (yet).

[squid_80]

A new attempt at multithreading: http://okejl.dk/dunstan/huffyuv.zip (yes, same place as the last build)

Again it's only on the yuy2/median method. In the config dialog set the number of threads with the spinbox at the bottom. Stick to powers of 2 (1, 2, 4 or 8). 1 thread is the same as regular huffyuv, so compare against that.
I'm seeing a ~12% gain on the HT machine I'm using for testing, with cpu usage sitting around 90%.

[Czarek Kwasny]

thanks a lot folks!
im into animtion and use intensively huffmann compression. im going to supply a64 x2 soon so ill definitely gain from the work of yours. :)

[Revgen]

@Squid

The multithreading works a bit, but unless your doing HDTV caps I doubt it makes much of a difference. It never uses more than 54% of the CPU load while recording with Dscaler.

Thanks alot for both this version and the YV12 one. The YV12 version is way faster than Lagarith's YV12 for capture and allows me to use it instead of FFDshow which is incompatible with Dscaler.

Thanks.

BTW I'm using an AMD X2 4600+ for these tests.

EDIT:

The YV12 version doesn't seem to work. I recorded with it and it's YUY2 according to VDub.

[squid_80]

Are you sure you set your capture mode to yv12? The codec doesn't downsample.

[Revgen]

Oh, I thought it did downsample. My bad. Lagarith downsampled, so I figured this one would too. Dscaler only outputs YUY2.

[squid_80]

Just thought I'd post the one-line avs script I'm using for testing:
colorbars(pixel_type="yuy2").bilinearresize(1280,720).trim(0,-1).loop(10000)
On the machine I'm using for testing, the original huffyuv takes 2:18. With multithreading it takes 2:04.

[Blue_MiSfit]

What kind of capture cards are you guys using to cap HD?? I assume an Aja Kona or maybe a blackmagic?

[CruNcher]

@easy2Bcheesy
could you look into LocoCodecs loosy mode and bench this im sure it has (after some optimization work) the chance to beat Cineform or at least be as good and fast. Btw the SSE2 compile seems borked at least it isn't loosless here on a AMD64 with SSE2 but fast.

[johnsonlam]

A new attempt at multithreading: http://okejl.dk/dunstan/huffyuv.zip (yes, same place as the last build)

I'm seeing a ~12% gain on the HT machine I'm using for testing, with cpu usage sitting around 90%.

Thanks squid_80!

I'm using Athlon64 DualCore 3800+.

I didn't do benchmark, but still can feel it's faster, it eliminate the delay when capture with Media Player Classic. The "huffyuv_ccesp-patch_025" need to delay voice 100ms.

For capture, it's nearly perfect, just add the missing word "Thread" besides the spinbox.

But when working with VirtualDub 1.6.16, must reset to single thread otherwise it'll crash ... can anybody solve the problem?

Thank you very much!

[squid_80]

Well this thread seemed to die, so I never bothered to upload a newer build. I did end up making an avisynth filter that generates custom huffman tables, and modified the codec config to be able to load them in... Had plans to implement "presets" i.e. about half a dozen new tables in the codec for better compression depending on source material... but didn't finish because no-one seemed to be interested.

[Czarek Kwasny]

i'm using huffmann compression while outputting animation footage from After Effects in HD resolutions. the output is RGB24 so i usually use Predict Gradient method. at the moment I'm unable to test the multi thread option, but will do as soon as i buy an x2 cpu.

[Shinigami-Sama]

had I the machine power to test that, I would be very interested squid, but sadly this is the life of a student

[squid_80]

But when working with VirtualDub 1.6.16, must reset to single thread otherwise it'll crash ... can anybody solve the problem?
How many threads were you trying? Only 2, 4 or 8 are valid values.

[dragongodz]

but didn't finish because no-one seemed to be interested.
i found this all interesting even though i dont have a dualcpu or dual core etc. i have just been rather busy with QuEnc etc. :)

[squid_80]

i have just been rather busy with QuEnc etc. :)
Hmmm, now I'm getting distracted wondering how fast a 64-bit mpeg2 encoder would be...

[johnsonlam]

Well this thread seemed to die, so I never bothered to upload a newer build. I did end up making an avisynth filter that generates custom huffman tables, and modified the codec config to be able to load them in... Had plans to implement "presets" i.e. about half a dozen new tables in the codec for better compression depending on source material... but didn't finish because no-one seemed to be interested.

Sorry, I didn't notice HuffYUV got the MT build until coming from a link somewhere, I think it's not no-one interest but they don't know, did you have a homepage?

AVISynth is a bit complex for me, so most of the time I stick to Vdub.

I'm very impress by the improvement, too bad using 2 thread killed Vdub, it's reporting memory problem. Can you please fix the problem?

A thousand thanks!


Rgds,
Johnson Lam.

[wereHamster]

squid_80, is your version opensource? I'd like to see how exactly you've multithreaded the encoder function.
In the last few days I've ported the HuffYUV assembler to amd64 but I can't compress more than ~120MB/s and that is much less than the original HuffYUV code

[squid_80]

It will be opensource when it's finished, but I'm still changing stuff. Basically when compression starts I set up worker threads, then to compress a frame I run the prediction function (not worth multi-threading) and split the image into slices passing one slice to each worker thread. The threads perfom the huffman encoding and the data is copied from each thread's output buffer to the main output buffer (This is slow but I haven't worked around it yet). In the output buffer each encoded slice is preceeded by the size of the undecoded data. The assembly code wasn't changed at all.
Did you write your amd64 code from scratch? I ported the original assembly to run on windows x64 and it runs a little bit quicker, although I think it could be tweaked a bit more by using the 64-bit shld and store instructions. I just never got around to doing it.

[Revgen]

For the record I haven't had a problem with the 2 thread version using Virtual Dub.

@Squid80

I'd be interested in your adaptive profiles. It sounds intriguing.

[wereHamster]

In the output buffer each encoded slice is preceeded by the size of the undecoded data. The assembly code wasn't changed at all.

I do something similar: my pixels are planar, not packed and I encode each plane separately, that could be multithreaded, but only up to three threads..

Did you write your amd64 code from scratch? I ported the original assembly to run on windows x64 and it runs a little bit quicker, although I think it could be tweaked a bit more by using the 64-bit shld and store instructions.

I copied the code from the original HuffYUV project and tweaked it a bit, like merged the shift and add_shifted tables to one at the cost that the huffman code can't be longer than 24 bits, but that could easily be fixed...

What do you mean by "64-bit shld and store instructions"? I've tried to replace 'shld' by 'shl' and 'or' but that didn't quite work and I was told that shld would be the best instruction to use in this situation, even on amd64.

[johnsonlam]

For the record I haven't had a problem with the 2 thread version using Virtual Dub.

@Squid80

I'd be interested in your adaptive profiles. It sounds intriguing.

Please be patient, I'm away from my dual core system for a day, tomorrow I'll be able to capture a screen and paste here.

[squid_80]

I do something similar: my pixels are planar, not packed and I encode each plane separately, that could be multithreaded, but only up to three threads..
I wrote YV12 functions as well, the only thing they do differently is use the Y table for the first two-thirds of the image, the U table for the fifth-sixth and the V table for the last sixth.

I copied the code from the original HuffYUV project and tweaked it a bit, like merged the shift and add_shifted tables to one at the cost that the huffman code can't be longer than 24 bits, but that could easily be fixed...
Why not 27 bits if you're storing the code and bitcount together in the same int?
What do you mean by "64-bit shld and store instructions"? I've tried to replace 'shld' by 'shl' and 'or' but that didn't quite work and I was told that shld would be the best instruction to use in this situation, even on amd64.
Use the 64-bit registers instead of 32-bit.
The 32-bit version does something like this:
sub cl,ch ; eax is the code, cl is bitcount
sub ch,32
shld edx,eax,cl
add cl,ch ; restore original cl (32 is added, but it doesn't matter because shld only looks at lower 5 bits)
mov [edi],edx
add edi,4
You could approximately halve the amount of memory writes with something like this:
sub cl,ch ; rax is the code (in high 32 bits), cl is bitcount
sub ch, 64
shld rdx,rax,cl
add cl,ch ; restore original cl (64 is added, but it doesn't matter because shld only looks at lower 6 bits)
mov [rdi],rdx
add rdi, byte 8
; Note the "byte" prefix - otherwise yasm uses 32-bit immediates

[wereHamster]

Why not 27 bits if you're storing the code and bitcount together in the same int?


I can't, "add ch,cl" would yield wrong values ;) but as I said, this could easily be fixed

[dragongodz]

Hmmm, now I'm getting distracted wondering how fast a 64-bit mpeg2 encoder would be...
pity theres no 64bit version of GCC for windows. :)

[johnsonlam]

Hi Squid_80,

Sorry for delay, gone a few days.

When I set to 2 thread, it'll crash, however single thread OK.
Athlon64 Dual Core 3800+, Virtualdub 1.6.16 (build 24463).

http://johnson.tmfc.net/file/huffyuv-err.gif

[foxyshadis]

Something interesting:
http://www.quicklz.com/

I might import this code into huffyuv, just to see how it compares to squid_80's multithreaded variation. Compression isn't amazing, but the speed is.

[johnsonlam]

Something interesting:
http://www.quicklz.com/

I might import this code into huffyuv, just to see how it compares to squid_80's multithreaded variation. Compression isn't amazing, but the speed is.

Oh! This is a really good news!

Looking forward to try your new QuickLZ version.

[wereHamster]

Something interesting:
http://www.quicklz.com/


Indeed, it's a very fast codec!

Too bad it's relies on 'sizeof(unsigned int) == 4' and doesn't care about endianess (so it won't work on ppc or my amd64 linux out of the box) but it's nothing that would stop me from using it, I'll integrate it into my 'seom' library after I make it truly portable.

Thanks for the link :D

[Pookie]

"Now compatible with x86, x64, IA64, Alpha, SPARC, MIPS, POWER and the like. For x86/x64: Increased average speed of compression by 3 Mbyte/s and decompression by 19 Mbyte/s on the test machines. Programming interface: Some arguments are now void* instead of char*. Bugs: None (upgrade not critical)."


http://www.quicklz.com/

[Adub]

Any news people? I am thinking about getting into capturing so this is kind of interesting.

[Blue_MiSfit]

I would be very interested in this also!!

[johnsonlam]

I'm still waiting for news about the SMP/Multithreaded Port of HuffYUV.

I guess ... since it's almost new year (just 2 or 3 days apart), they should spend more time with their family, so please be patient.

Can't imagine eating turkey and coding at the same time :)

[Adub]

I can. ;)

[3ngel]

Hi,
i've encountered this thread, and i'm very interested in it.
The last build link available has some improvement effects in performance when used with lossless RGB compression in huffy control panel?
Thank you very much

[smok3]

count me in (my usage would be realtime playback of 1280x720/25p material, so i would need mostly fast decompressor), dual xeon 2.8 here.

[squid_80]

The build I made was only multi-threaded for YUY2 (not UYVY, which is what virtualdub's fast recompress will choose) median mode. Since then I've got a dual-core machine and the performance...sucks. Multithreading could be used to increase compression but at the moment I don't know how it could be used to increase the speed. Turning the codec into a directshow encoder might be viable (directshow codecs can be used for capturing with the latest virtualdub) since it doesn't have the one-frame-in-one-frame-out limitation of vfw but at the moment I don't have the time.
What would be interesting is if someone modified it to use a 16-bit alphabet instead of 8 bits. It would only work for YUY2 (or possibly RGB32) and would require a modern machine with a big cache since the huffman table would take up 256k instead of 3k (1k * 3 tables). Reduce that by a bit since a lot of possible YUY2 values aren't used. As it is the code uses no prefetching and no temporal writes so it's possible the tables are getting dumped out of the L1 cache all the time anyway.

[3ngel]

So, if i've understood well performance can't be increased 'cause VFW codec can accept only one frame at time, and in this case a multithreaded mode could not benefit of processing two (or more) frame at the same time?

If that's the case a slight modification could be done, in order to split the single input frame into two (or more) subframes that would be processed multithreaded in encoding mode, then reassembled in decoding mode.

[squid_80]

http://forum.doom9.org/showthread.php?p=865593#post865593
It doesn't work because A) Thread control takes equal or more time than the encoding and B) There's no way to predict how long the encoded stream will be, so each thread has to write to separate buffers which are combined at the end.

[3ngel]

Oh, i see, you did already do the splice solution... and so it doesnt' improve?
Kinda strange. The threads and buffer overhead would not to be so high in order to vanish the interlacing solution.

[IS2000]

I'm new to this forum (my first post here) but I have been keenly following this thread for sometime now. I work in the digital video hardware design and got interested to learn more about HuffYUV (Possibly thinking of doing this in FPGA).

I'm using all the latest versions of Virtualdub and HuffYUV (multi-threaded version for predict median). I've not been able to do real time compression or decompression of either 1080i or 1440i or 720p on these two systems listed below;
1. P4 2.8Ghz 1MB L2, 2GB DDR
2. Pentium D 945 3.4Ghz, 2GB DDR2

I would like suggestions from you guys for a system (Prefereably Intel based) that will 'sustain realtime'! HuffYUV codec for HD resolutions (1080i, 1440i, 720p). 1080p is not a requirement.

[3ngel]

@squid_80
I take the occasion to say, what you think about doing an optimized DirectShow Huffy decoder, as a first step for a DirectShow multithread encoder?

[squid_80]

I'm actually quite bored today so I was going to try out the directshow idea. Using the CTransformFilter class makes writing directshow filters a breeze, so give me a few hours and I should have something.

[3ngel]

Fantastic, i'm waiting for it :)

EDIT: Don't forget to add a good RGB32 colorspace output

[easy2Bcheesy]

I'm new to this forum (my first post here) but I have been keenly following this thread for sometime now. I work in the digital video hardware design and got interested to learn more about HuffYUV (Possibly thinking of doing this in FPGA).

I'm using all the latest versions of Virtualdub and HuffYUV (multi-threaded version for predict median). I've not been able to do real time compression or decompression of either 1080i or 1440i or 720p on these two systems listed below;
1. P4 2.8Ghz 1MB L2, 2GB DDR
2. Pentium D 945 3.4Ghz, 2GB DDR2

I would like suggestions from you guys for a system (Prefereably Intel based) that will 'sustain realtime'! HuffYUV codec for HD resolutions (1080i, 1440i, 720p). 1080p is not a requirement.

Chances are it is your hard disk array that is the problem. I have captured 24-bit RGB at 720p/60 with Huffyuv using a two disk RAID-0 array. I'm also sure I've done YUY2 1440x1080 at 30fps with no problems whatsoever. I have captured YUY2 720p/60 using Huffyuv with no problems whatsoever either.

I have found that capturing with Huffyuv with a preview window drains a lot of performance. Turn off the preview window and see how you get on.

[squid_80]

OK, here's some stuff to test:
First is the Directshow huffyuv encoder (http://members.optusnet.com.au/squid_80/HuffyuvDS.zip). It only supports the YUY2 median method; if you feed it RGB24 it will be converted to YUY2. It is multithreaded and the bitstream isn't backwards compatible...
...so here (http://members.optusnet.com.au/squid_80/huffyuv%20mod.zip)'s a modified version of the vfw codec which can decode it properly. It might pay to disable huffyuv decoding within ffdshow since it tries to handle it but fails and you end up with a grey screen.

I managed to get a few benchmark figures using graphedit and Elecard's Chegepuga filter. For encoding a 1920x1080 YUY2 input:
HuffyuvDS: 115.31 fps
Original: 70.44 fps
For encoding 1920x1080 RGB24 (converted to yuy2 by the codec):
HuffyuvDS: 69.90 fps
Original: 32.75 fps

Of course these figures are completely raw, the input was the same frame being fed over and over and the output was being dumped down a sink - you wouldn't see these figures with real sources. But in theory the performance increase of the codec should stay the same.

[3ngel]

Good squid_80, but i'm waiting for the RGB32 compatibility in order to do some good tests :) Thanks anyway for now.
Oh, a question. Why didn't you do a DirectShow .ax version of the decoder? It's the same?

[squid_80]

Yep, .ax is just .dll renamed. It still has all the active movie junk in it required for self-registering with regsvr32.

[3ngel]

I see, good then, so i'm waiting for a RGB32 version to test :)

[IS2000]

Chances are it is your hard disk array that is the problem. I have captured 24-bit RGB at 720p/60 with Huffyuv using a two disk RAID-0 array. I'm also sure I've done YUY2 1440x1080 at 30fps with no problems whatsoever. I have captured YUY2 720p/60 using Huffyuv with no problems whatsoever either.

I have found that capturing with Huffyuv with a preview window drains a lot of performance. Turn off the preview window and see how you get on.

Thanks for the response.:thanks:

I have RAID-10 setup with 4 drives (7200 rpm). The HuffYUV compressed data (1080i,720p) when played back via VirtualDUB, with both in/out preview disabled, hardly reaches 12fps@1080i, 45 fps@720p (59.94).

I now have a system with Intel Core2Duo E6600 (2.4Ghz, 4MB L2 Cache), Hardware RAID-10 4 Drives on PCIe, 4GB DDR2-800. Here are the numbers with this setup;

Application: VirtualDUB
Compressed FIle Format: HuffYUV predict left
Preview: OFF

1080i(29.97) => 18 fps sustained
CPU Util => 50% of both cores

720p(59.94) => shall try today

I'm lost as to why my 'fps' numbers are that low when compared to some of benchmarks in this thread.

Could you share more about your benchmark setup?

[easy2Bcheesy]

Not sure what to say except that I have achieved 720p/60 capture into YUY2 Predict Left (Fastest) on a P4 3.0GHz - and that is without the multithreaded version at all!

Before I opted to embrace CineForm compression I used Huffyuv all the time.

What capture speeds are you getting with no compression at all? Are you sure you are feeding the codec YUY2 input?

[squid_80]

Question: Does anyone actually use huffyuv to compress RGBA? Not RGB32 (8 bits per channel + 8 bits padding) but true 32-bit RGBA (8 bits per R, G, B and alpha). The reason I ask is because of how the original huffyuv is written; to make it accept RGB32 you have to turn on the "Enable RGBA" option, and it includes the padding byte in the compressed bitstream (poorly compressed, since there's no tailored huffman table for that channel). I'm thinking it would make more sense to always drop the alpha channel and save about 30% in output size.

Directshow differentiates between the 2 types with MEDIASUBTYPE_ARGB32 and MEDIASUBTYPE_RGB32. If I weren't so cynical I could use the input type to decide what to do with the padding byte... But IMO that's just asking for trouble.

[Shinigami-Sama]

big question

is that software raid?
if it is I'll bet thats your bottle neck....

[3ngel]

Personally i don't use RGBA. But RGB32 is important for alignment reason (i read on few places that GPU algorithms can take advantages of 16* multiplier alignment) and of course for quality reason 'cause for maximal quality GPU has to be fed with already decoded RGB values.
So if you want to drop RGBA support i don't have problem, but of course i suggest not to drop RGB32 support.

[easy2Bcheesy]

What sort of hardware do you have that gives you a RGB32 HD capture? Just about every commercial HD card centres on YUY2 - though 8-bit and 10-bit precision is often offered (eg Blackmagic/AJA etc)

[smok3]

Question: Does anyone actually use huffyuv to compress RGBA? Not RGB32 (8 bits per channel + 8 bits padding) but true 32-bit RGBA (8 bits per R, G, B and alpha). The reason I ask is because of how the original huffyuv is written; to make it accept RGB32 you have to turn on the "Enable RGBA" option, and it includes the padding byte in the compressed bitstream (poorly compressed, since there's no tailored huffman table for that channel). I'm thinking it would make more sense to always drop the alpha channel and save about 30% in output size.

Directshow differentiates between the 2 types with MEDIASUBTYPE_ARGB32 and MEDIASUBTYPE_RGB32. If I weren't so cynical I could use the input type to decide what to do with the padding byte... But IMO that's just asking for trouble.
i do use huff for rgb + alpha daily.

[sagacity]

What sort of hardware do you have that gives you a RGB32 HD capture? Just about every commercial HD card centres on YUY2 - though 8-bit and 10-bit precision is often offered (eg Blackmagic/AJA etc)

When recording SD/HD 4:4:4 material it is typically provided as 10-bit RGB.

[3ngel]

@squid_80
Any news for the RGB version of the codec?

[zambelli]

Just about every commercial HD card centres on YUY2 - though 8-bit and 10-bit precision is often offered (eg Blackmagic/AJA etc)
It would indeed be interesting to have a 10-bit lossless codec as an alternative to the commercial solutions such as Cineform.

[zambelli]

Any progress on HuffYUV development? It'd be really great to have a version that surpasses both 2.1.1 and Ffdshow versions in terms of feature set and performance. Right now you often have to pick one or the other and they're not necessarily mutually compatible.

[squid_80]

I dream of putting out huffyuv v3.0, with the following features:

YV12 encoding/decoding, compatible with the existing ffdshow implementation
Multithreading for all encoding modes (also for decoding, but that's less of a priority)
Proper backwards compatability to v2.x i.e. can decode anything produced with v2.x and encodes made with 3.0 that use advanced features are rejected by earlier versions
Full directshow and vfw codec in one dll
Proper ARGB and RGB32 support
A selection of preset huffman tables tailored to specific material as well as support for custom tables generated by an avisynth plugin
SSE speedups for the prediction functions

I've done little bits and pieces of all of these things, just don't have the time to put them all together into one tidy package.

[3ngel]

Full directshow and vfw codec in one dll
Proper ARGB and RGB32 support
Mmmm... :D

[lilhobo]

hey guys, the future is a dream, but how do u use huffyv for the present ?? :D

i have the 2.11 with cce patch but realplayer and wmp dont play it??? is this just the vfw codec, and i need ffdshow to do directshow?

[sebastian___]

I read all of the posts here but I'm afraid I have to ask again :
So is there a newer build of Huffyuv (or similarly faster codec) which takes advantage of multi core CPU's ? And I'm only talking about full lossless 24 bit RGB.
- Because I (and many others) have a quad core Intel which can use this, I think.
Thanks.

[Blue_MiSfit]

Lagarith is multithreaded...

~MiSfit

[Adub]

Well, Squid said he had pieces of the overall puzzle, he just hadn't put them together yet. Maybe he will soon?

[Blue_MiSfit]

That would be great, as HuffYUV is stupid fast to begin with... :)

Lossless 1080p24 HD-SDI capture to RGB24 HuffYUV would be very nice.

[squid_80]

I'm working on adding a new compression method (similar to ffdshow's adaptive tables). Can't promise anything at this stage since it's just an idea that I haven't had time to implement.

[Adub]

I think I speak for all of us when I say, "Cool! Keep us updated!".

[squid_80]

http://members.optusnet.com.au/squid_80/huffyuvadapt.zip

Look in the encoder config and you'll see an adaptive huffman tables option. Turning it on should give slightly better compression but the files will be incompatible with older huffyuv builds (and ffdshow).
After lots of testing I realize now this isn't the best way to improve compression. The problem is huffman compression works best when the input symbols have probabilities that are powers of 2 - quite often the probabilities of the 256 input symbols will be skewed so much that one symbol has a probability of >70%, especially with digital sources. Huffman is inefficient with any probability more then 50% which is evident if you try and zip or rar the huffyuv compressed avi file - frequently it can be compressed by a further 50%.

[Boulder]

Did the dreamt v3.0 ever come to life?

[squid_80]

Not quite. I think last time I tweaked the version number I was up to 2.4.6 - featuring YV12 support (not fully complete, but good enough), adaptive tables, median mode for RGB (practically redundant) and a complete DirectShow encoder interface. Multi-threading was abandoned since I just couldn't seem to make it work. Never got around to making it compatible with ffdshow either.

[johnsonlam]

Not quite. I think last time I tweaked the version number I was up to 2.4.6 - featuring YV12 support (not fully complete, but good enough), adaptive tables, median mode for RGB (practically redundant) and a complete DirectShow encoder interface. Multi-threading was abandoned since I just couldn't seem to make it work. Never got around to making it compatible with ffdshow either.

Thanks for the improvement.

What I concern is HuffYUV is the minimal delay, if the compression is too high it may affect the "on-the-fly capture with acceptable compression ratio" purpose.

There're some codec got really good compression ratio, but lossless with low latency (such as Largarith) seems all spin off from HuffYUV.

Sadly, largarith have few bugs unresolved.

[squid_80]

If you find bugs in lagarith, report them to the author. He normally fixes them pretty quick.

[johnsonlam]

If you find bugs in lagarith, report them to the author. He normally fixes them pretty quick.

He's nice, I've contact him years ago.

The problem is I can't reproduce the bug, it happen only under some special circumstances which I don't know.

When Largarith fail I have to fall back using HuffYUV.

[mariush]

I'm sorry for bringing this old thread back.

Have you guys checked the multithreaded Huffyuv from this page ?

http://home.h01.itscom.net/para/intro/huffyuv-mt/

I've checked the thread and couldn't find any reference to it. Any oppinions?

I'm currently doing lots of encodings where I'm splitting 30-50 minutes videos in 5-8 minutes intervals (which have to be stored lossless for various reasons) so I'm hoping to get better decompression speed (it feels like xvid encoding speed is limited by the huffyuv decoding) so overall i'd get much faster encodings.

I'm just worried there may be some bugs in it that would make me waste a lot of time.

[smok3]

lagarith does work well for me on my new work machine.

http://lags.leetcode.net/codec.html

(no, i did not try huff mt yet)