"HuffYUV revisited" 2.2.0 released

[sh0dan]

I have been doing some modifications of HuffYUV to make it better for my NLE-tasks, and I thought some of you might have some use for it too.

Here is the changelist:
* Added "Reduced resolution". This will save your file in HALF the orginal resolution, and upscale the video on the fly. Lossy, but very fast!
* HuffYUV is now storing interlaced mode in the AVI-file. Now interlaced files are properly decoded!
* Added MMX optimized YUV -> RGB conversion routines.
* HuffYUV will now suggest to store RGB32 (RGB with alpha), even if it is disabled. Alpha information will however be removed when on.
* HuffYUV should now support all resolutions flawlessly. Do however not that it is not recommended to use a resolution that isn't divideable by 8, when using Reduced Resolution, and YUY2 naturally must med divideable by 2.


It _should_ be 100% backwards compatible with HuffYUV 2.1.1, but HuffYUV 2.1.1 will not be able to decode all 2.2.0 created files.

Get it from: http://cultact-server.novi.dk/kpo/huffyuv/huffyuv.html.

Please report any problems, and I'll see if I can help.

[DDogg]

I am really glad you are taking a look at huffy, so thanks very much for the work.

I tried a little testing. Both VDub and my Winfast capture software crashed hard when I tried to use the reduced resolution checkbox. Any suggestions? The test resolutions were 720x480 and 640x480. I tried many different settings but that did not seem to make a difference.

[sh0dan]

:thanks:

Yet another stupid bug fixed! Archives have been updated.

[DDogg]

That fixed it, thanks :)

Sh0dan, the only thing I am wondering about is the reduced stuff seems to look pretty bad. By that I mean the letters of a title are scored through with lines as if missing every other line. Since I know you are a bit of a perfectionist, I don't think I am seeing what you intended.

[sh0dan]

It's supposed to be ugly. ;)

When I do editing and compositing/postprocessing speed is more important than quality, since I'm dealing with some quite highres material. So it matter quite a bit that huffyuv is four times as fast at delivering the material. And when I'm done editing, I simply replace the files with full-resolution ones and hit "render".

This is why it's for NLE, and not capturing.

[DDogg]

OK, I understand now :) Thanks for the explanation.

[Wilbert]

I almost missed this thread :)

Sh0dan could you include the changes of 0.2.3 (download section of Doom9). It's a fix for appending two huffyuv clips.

[sh0dan]

I'll do a diff and see what the changes are. Apparently I've missed the 0.2.3 update.

[2ZOD.COM]

This is awesome. I can't wait to try it out. Thanks.

[Schlumpf]

Neat!
Why did you hide this in the NLE-forum, where I hardly ever look? (First time today, to be precise ^^° )

[Arachnotron]

Great to see my favorite codec is still being improved! Many thanks!!

My apologies if I ask something I should have known, but I noticed the 0.2.3 version in the download section has now been replaced by the 2.2.0 version. Does this mean the changes in the 0.2.3 version were superseeded by this one? Or are there now two versions?

[Zarxrax]

This new huffyuv is crashing any program that tries to access the files created with it. Files were created with default settings. Virtualdubmod reports the following:

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'huffyuv'...

...while decompressing video frame 0 with "Huffyuv v2.2.0" [biCompression=55594648] (VideoSource.cpp:1823).

[Zarxrax]

Here is a sample clip that I encoded. It is 480x480 resolution.
http://zarxrax.kicks-ass.net/extra/147.avi
The small size makes me wonder if there is even actually encoded the frames, as most of my files encoded with the old huffyuv were about 10x larger.
Is it possible to extract even a single frame of video from this? The content is semi-important, but I can't remember exactly *what* the content was, so I'm unable to recapture it.

[Arachnotron]

I can't help you with the huffyuv problem, but I can get a frame from it using the viewer from Total Commander. Here is s acreendump, so you know at least what was in it :). The avi won't play on my machine either.


147.png (http://www.arachnotron.nl/temp/147.png)

[Zarxrax]

O.O Wow that looks seriously screed up. It was just enough to jog my memory after a moment though :)

[section31]

Hi, I just installed huffYUV b/c I wanted to output my premiere project using a loseless video codec. My problem is when I export it via premiere I get the entire video looking like this with the audio running fine in the background.
http://davesrig.us/misc/pics/huffyuv2.2.jpg

I tried using this codec in virtualdub to see if it was just premiere, but everytime I would open the video created by virtualdub in windows media player it crashes. I also tried enabling console window logging but no window would popup during compression. Any ideas what my problem could be...Perhaps a conflict with another codec or something or a previous version of huffYUV.

[BioByte]

I've the same problem. New version of huffuyv crash any program which tries to access the files created with it.
Crash details:
An out-of-bounds memory access (access violation) occurred in module 'huffyuv'...
...while decompressing video frame 0 with "Huffyuv v2.2.0" [biCompression=55594648] (VideoSource.cpp:1516)...
...while running thread "Processing" (thread.cpp:105).

[section31]

IC, well for now i'm using mjpeg..but i really want to get this hufffyuv working...I really like its speed.

[Arachnotron]

I have no problems with it. Capped at 720x576 and played back again without problems on a P4.

This is with the field treshhold at 288, and no option enabled except "Enable full size output buffer". Both compression methods ar set to best.

[Zarxrax]

After a bit of messing around here is what I discovered:
Bad output files are only created when it encodes to RGB. Converting to YUY2 will output correct video.
Source file is being passed in as RGB32.
Enabling Reduced resolution causes RGB mode to work.

Hopefully this information is helpfull in fixing the problem.

[sh0dan]

I will have a look at it ASAP. The CCE-patch should also be upgraded to 0.2.3! Thanks for the detailed information!

Until then stick to plain old 2.1.1!

[Zarxrax]

@Shodan: this is coming completely out from left field, but do you think you might be able to add a special optimization for frames that are empty? i.e. solid black in every channel. I often encode overlays and such out of after effects, and its mostly just empty frames, but they still use up quite a bit of space in huffyuv, totalling a few gigabytes over a 15 or 20 minute long clip.
I've recently been using corepng for this sort of material, as it can compress the files down to about 40-50mb, as opposed to about 4-5gb with huffyuv. It's about 3-4x slower though.
So anyways, I was thinking it doesn't seem like it would be so difficult to add in a special case for empty frames, so I was wondering if this might be a possibility? Another use for such a feature would be for the alpha channel. It seems strange to have the user check a box to indicate whether to use the alpha channel data. If there were an optimization in place to compress an empty channel, when people could leave the rgba box checked all the time and not have to worry about having gigabytes added to the output file. If the alpha data exists it would get compressed as normal, if it doesnt exist it would get compressed so small that its negligable. Its annoying sometimes to encode something and realize that you forgot to uncheck the rgba box, and the encode is eating a hole in your hard drive :p


But anyways, thatnks for your work on this codec. I have been trying the reduced resolution option this past week and it is incredibly great, I can't believe no one did something like this already :)

[zettai]

@sh0dan: This is completely selfish request-making from me so feel free to just flat-out refuse :)

HuffYUV is an invaluable codec. It's fast,it's pretty stable and it's simple. Now, I know there are all sorts of codecs out there which can do all kinds of colorspaces, delta frames and whatnot but essentially I'd like to see HuffYUV be extended enough that it's flexible but not so much that it loses its simplicity and stability.

In short I'd love to see a HuffYUV that had a more wide-ranging acceptance of colorspaces. YV12 would be great, obviously, and possibly some 4:4:4 YUV too in anticipation for future avisynth capabilities - maybe with YUV+alpha support too?

I think it would be great to have these colourspaces all under one roof with the simple fast compression technique that huffyuv is known for. (Oh and before you mention ffvfw I'll stress the word stability :P)

[zambelli]

Nice work. Will you be using this NLE forum as the main discussion forum?

[thastarter]

what's the deal with the new Huffyuv codec?
when it's gonna work OK? are the bugz fixed to work with Premiere?

[bastel]

Originally posted by sh0dan
I will have a look at it ASAP. The CCE-patch should also be upgraded to 0.2.3! Thanks for the detailed information!

Until then stick to plain old 2.1.1!

Hmm darn forum system didn't allow me to post for 5 days after registering, and then i forgot about it...

Well anyway, you better use 0.2.3.
The only difference should be in one method, it's about initializing some datastructure differently. But this way those bytes aren't set to random values depending on your application and you can join huffyuvs made with different programms in vdub. I made this change on request by some friend.

There is also a 0.2.4 that stores the interlaced flag, too. But differently than your codec does it. And since I can't remember the reason why i did it this way (not a simple bit in the extra[3] field) - i think it was to detect garbage there, but then old versions initialized that field to 0, too :) - i should remove 0.2.4. And do a 0.2.5 that stores it like your version does. This way there would be at least some compatibility...

bastel

ps: it's not so cool that the old berkley huffyuv site points to avisynth site now, not the new huffyuv site.

pps: i guess i am hiding my huffyuv ccesp homepage too well ;) but there were never any real plans to release the patched huffyuv to the general public, the idea was that it would make its way out there or not. it was made for friends after all.

[Sigma9]

I encountered similar problems: it seems impossible to export from P7 using huffyuv. Tried all versions/all settings/all color models.

However, as I can only produce errors - new clue as to WHY?
VD(mod) is lucky with all these huffyuv versions, so it seems a problem related to Premiere(7).

@shodan (not nagging, just asking info):
is there anything to be expected soon in that direction? - Otherwise, I'd have to go and buy another large HD 'cause I am stuck ;=)


/sigma9

[Arachnotron]

VD(mod) is lucky with all these huffyuv versions, so it seems a problem related to Premiere(7).

One difference between the two that might be related is that vdub works in RGB colorspace while the latest Adobe Premiere Pro can work in YUV.

[Flexy]

hi,

the 2.2.0 is definetly a no-go.

i cannot use this codec in *any* player, WMP, Zoomplayer etc.
2.1.1 works tho

[Gambero]

Hi, someone know how to open avi files encoded with huffyuv 2.2 in pinnacle studio 8? when i try to open a file the program crash!!!
why?!?

ps: in virtualdub the avi play good!!

THANKS

[WarpEnterprises]

BUMP.

I get crashes with all RGB settings.
No crash for YUY2 settings.
No crash for RGB and reduced resolution.

Tested on W2K with VD and WMP.

[Zarxrax]

Shodan already stated that people should go back to version 2.1.1 for now.

[Longinus]

It works for me, and the reduced resolution is a REALLY nice thing..
I'm now using this new huffyuv instead of the old ones, BUT I can't seem to be able to open files I encoded with 'v2.1.1 - CCESP Patch v0.2.2'. My Field Threshold is the same, it should work. (I get corruped output... just like when you change the field threshold)
I had to install the old huffyuv with another fourcc, and then force it using virtualdub... to finally convert to the new huffy...

Anyway.. I hope you continue working on huffyuv... because It's a nice codec and I use it in all my movies.

[North2Polaris]

I have a HUFFY field threshold question that I have been puzzling over.

http://cultact-server.novi.dk/kpo/huffyuv/huffyuv.html

"If you're processing NTSC video, you should set it to 240, so that material with more than 240 lines will use interlaced compression. For PAL the original value of 288 is right."


www.digitalfaq.com/capture/atiavi/atiavi.htm

“When capturing HuffYUV AVI from tv or VHS source, encode interlaced! You must leave the video interlaced. Your source is interlaced. Interlace requires more than 280 lines of resolution in the digital world, so PAL users can choose 288 or 576 and NTSC users must choose 480. Removing the interlace lines kills quality and causes stair-steps to appear in your video, most noticeably on straight lines.”
It seems that for NTSC users, the advice is quite different between these two sources: 240 versus 480 for interlaced compression.

Would any of the contributers to this thread be able to shed some light on this?

Thanks.

[numlock]

Any updates on bug fixes ??

[vispgraedde]

Could anyone answer why this version of the codec is still on doom9's download page?
It IS after all b0rked and unusable for a lot of people.

Just the other day a friend of mine downloaded this, encoded one thing to huffy (took many hours to encode) and then find that the encode is useless.

Please reinstate 2.1.1 (with or without ccesp patch) on the download page until 2.2.x is fixed.

[Longinus]

I don't see why people say it's broken.... I'm using it right now and it works just fine.. BUT it can not open older huffyuv videos (for me anyway)...

But it should work with videos encoded by himself...

[vispgraedde]

If you had read through the thread you would see that it does NOT work for RGB settings.

It's broken fair and square and it should be replaced until fixed. Or at the least a warning that it doesn't work in RGB.

[bastel]

Originally posted by North2Polaris
I have a HUFFY field threshold question that I have been puzzling over.


It seems that for NTSC users, the advice is quite different between these two sources: 240 versus 480 for interlaced compression.

Would any of the contributers to this thread be able to shed some light on this?

Thanks.

Simple: If you capture pal material and are capturing 288 lines, the video is progressive as you throw away a field. If you capture at 576 lines then you need interlaced encoding. So the field threshold of 288 works here.

If you are capturing 240 lines ntsc, then it's the same as with 288 for pal and if you do 480, this is equivalent to 576 pal.

The problem of the hardcoded 288 value is that if you have the funky idea of capturing, say... 288 lines with ntsc. There you need interlaced as you use data of 2 fields. It will look ugly, tho.
Just capture at 240/480 and 288/576 only and you shouldn't run into problems if you leave the threshold at 288.

If you work with progressive material (for example you ivtced some ntsc material or have a progressive camera), and are sure that even at 480/576 lines your video is progressive, then you can set the threshold to that value to gain better compression.

huffyuv ceesp patch 0.2.4 stores the interlace setting in the file, so one can change the global setting, it does not affect the recorded files. (even tho the way it stores it is kinda akward - and I didn't even smoke something when writing that and still wonder why I did it this way. I guess 0.2.5 is necessary :P)

bas

[North2Polaris]

bas,

Thanks for your reply. Let me make my question more specific because I am still not sure about this.

I am making a NTSC TV capture using BTwincap at 712x480. Do I set the HUFFY field threshold to 240 or 480 or leave it at the default of 288?

Based on your reply, I should not set the field threshold to 480 because the captured video is interlaced, correct?

If this is correct, then the advice on Lord Smurf's website is not correct.

North

[bastel]

Originally posted by North2Polaris
bas,

I am making a NTSC TV capture using BTwincap at 712x480. Do I set the HUFFY field threshold to 240 or 480 or leave it at the default of 288?

Based on your reply, I should not set the field threshold to 480 because the captured video is interlaced, correct?

If this is correct, then the advice on Lord Smurf's website is not correct.

North

Yeah you can leave it at 288 (or set it to 240). If you have set it to 480, compression will suffer but you don't really break the video (imho).

But why 712 pixel? Not 720?

bas

edit: hmm I went to this "Lord Smurf's" page and yeah, the advice starts correctly but in the end reverses what it wanted to tell :)
Just leave it at 240/288 according to what you are usually processing and you cannot go wrong. The 480/576 setting is only there for people that process full d1 progressive video all day long, as you can save quite a bit of hdd space this way.
Don't forget: changing the setting often with patch versions <0.2.4 is quite bothersome, as they don't store the setting in the file.

I wonder if I can attach the 0.2.5 patch to this post somehow or so...

[North2Polaris]

bas,

Thanks. The added explanation clears this up for me!

As for why 712x480, please see "Determining the capture window of a capture card" at:

http://www.arachnotron.nl/videocap/site/capture_area2.html

I have a BT878-based capture card and use the BTwincap driver.

See also this recent thread:

http://forum.doom9.org/showthread.php?s=&threadid=72856&highlight=width+capture+card

Wilbert and others are working on a revision to the capture guide that I believe will cover this.

North

[bastel]

Originally posted by North2Polaris
bas,
As for why 712x480, please see "Determining the capture window of a capture card" at:

http://www.arachnotron.nl/videocap/site/capture_area2.html

I have a BT878-based capture card and use the BTwincap driver.

North

I actually read that after editing my post...
It has been a long time since I captured anything and back then nobody cared about aspect ratios, one could be happy if they understood lurker's guide. It seems that has changed in the meantime :)

Somehting nags me about that guide, though. The measurement dvdr.. I know standalone dvd players that shift the image to the left or right if you select rgb compared to svideo/composite. So I wonder how reliable this method is.

So is it possible to have file attachments here? I kind of have no website for the latest patch version.

bas
(who always liked avi_io that could keep perfect sync for video and audio no matter how many frames on dropped)

[North2Polaris]

bas,

See the following post in the Capturing Video forum:

http://forum.doom9.org/showthread.php?s=&threadid=76396

Perhaps this will help.

North

[Arachnotron]

@bastel

This is of-topic, so I will be brief

Something nags me about that guide, though. The measurement dvdr.. I know standalone dvd players that shift the image to the left or right if you select rgb compared to svideo/composite. So I wonder how reliable this method is.

Since you determine the distance *between two vertical lines* it does not matter if your DVD has shifted the pic. You only determine the width of the window, not it's offset. (I originally intended to include that too, but had to take that out again exactly because of the reason you mention.)

If you have any further questions, just bump this (http://forum.doom9.org/showthread.php?s=&threadid=66191) thread.

[North2Polaris]

@Arachnotron,

Do you ever get to stop being an "Absolute Beginner"? :)

North

[Arachnotron]

nope, I just find more complicated ways to ruin them... :D

[vispgraedde]

Since doom9 STILL link to this broken version of the codec I have to yet again request that it is removed, or FIXED, or PUT UP A WARNING THAT IT CAN NOT COMPRESS RGB.

It can still decode old RGB huffy's so the problem is with 2.2.0 and compressing RGB. Sizes of these "RGB" huffy's are much smaller than they are supposed to be. Not equal to the YUY2 huffies... But about the same size... As if the R channel is compressed as Y and GB as UV (only getting partial data since those are of lesser resolution), and later when this data is being decoded, you get access violations because the decoder expects more data than is actually available.

I don't know exactly how the source got barfed up and I don't have time to diff sources just to find out.

How hard can it be to replace a link on the download page? Or add a note? Or how about someone actually FIX the problem?

@Sh0dan: It's been around 5 months since you said you would look at it ASAP... have you really been that busy?

[numlock]

Question: If I undestand it correctly te latest HUFFYUV version is broken when using RGB comprtession. BUt is it safe for YUY2, cause that's the only one I use ?

Thx

[vispgraedde]

YUY2 is safe afaik.

[Wilbert]

How hard can it be to replace a link on the download page? Or add a note? Or how about someone actually FIX the problem?
Why don't you send Doom9 a pm asking to replace it with v2.1.1 CCE patch 0.2.5?

[North2Polaris]

Doom9 has replaced version 2.2.0 on the download page with:

http://www.doom9.org/Soft21/Codecs/huffyuv_ccesp-patch_025.zip

I sent a PM to Doom9 not long ago about the concern raised in this thread and he sent the following response:
Hi

I'm aware of that but I haven't managed to find a "safe" version.. that's why I'm still stuck at the latest bugged version. I even asked sh0dan but he couldn't help me either. If you know a place to get a working version please let me know.

Doom9
There is a lot of energy that goes into maintaining a site like this and much work goes on behind the scenes.

[Backwoods]

I'd still like to try out the 2.2.0 version, does anyone have a copy on their HDD still?

[keys]

I'd still like to try out the 2.2.0 version, does anyone have a copy on their HDD still?

ftp://141.53.8.34/pub/video/codecs/huffyuv-2.2.0.zip
ftp://194.126.98.42/windows/codecs/huffyuv_220.zip

The first download contains just the dll and the inf. The second download contains all the original release files. Sorry it's taken 14 months for someone to reply to your post. lol

[Backwoods]

Better late than never. Thanks!

[PhillipWyllie]

Does anybody know what the latest version is?

[Zarxrax]

Does anybody know what the latest version is?
v2.1.1 CCE patch 0.2.5 - this should be available from doom9's download page. You should not use another version. If you want a more efficient codec you might try the Lagarith (http://lags.leetcode.net/codec.html) codec.

[Longinus]

Version 2.2.0 is safe for YUV2... I use it a lot.
When I need RGB, I use the Lagarith codec like Zarxrax said.

[PhillipWyllie]

What's the patch for? Oh I use 2.2.0 for YUY2 and have no probs.

[keys]

Interesting to know about 'Lagarith' Zarxrax - many thanks.

[nibbles]

In post #54 above, Keys provided links to Huffyuv 2.2.0.

http://forum.doom9.org/showthread.php?p=780088#post780088

But the links contain different versions of Huffyuv unfortunately.

1st link: huffyuv.dll 2.1.1 CCESP 0.2.2 12/8/2001 (38912 B)
2nd link: huffyuv.dll 2.2.0 12/20/2003 (45568 B)

Good luck,
nibs