huffyuv help

[liquidr0x]

i'm not sure if this is in the right category, so forgive me if i posted in the wrong forum

I am using 64 bit windows XP if this is relevant to my problems

i am attempting to convert bmps to avi with huffyuv 2.2.0 (2.1.1 gives me a 3x bigger filesize, and ive gotten good results with 2.2.0 in the past on 32 bit windows)

the problem is i cannot get the rendered files to playback on any media player (crashes all of them, only 4:2:2 encoded video works but with bad results).

i've been messing around with this codec so much that i have lost touch with default settings and such, basically i just need this thing to work and i need to know if i need to reformat or what..

i have huffyuv enabled in ffdshow (encode and decode, fourcc is HFYU, colorspace is YUY2, predictor is set to median, with adaptive huffman tables enabled) -- played with these settings too with no avail

ive played with all the settings in vdub under compression but alas no success also

Things i need to know:

-Default "color depth" settings for huffyuv or the best settings (i can only get playback with with 4:2:2 (UYYY) and 4:2:2 (YUY2) and it doesn't play back smoothly at all)

-if i need to reformat to get the avis to playback (ive deleted huffyuv from windows codec settings, unregged it in zoom player) --- i am assuming this is the case. i am 75% sure just need some feedback

Thanks for taking the time to read my unorganized long post, any feedback is appreciated

[aedipuss]

huffyuv is normally used as a lossless intermediate file format. it's not really meant to be played back. why are you using it? what is the end result video for? there are lots of other more useful formats.

[liquidr0x]

yes i am aware that it is a lossless codec. I am using it to make uncompressed avis for a gaming movie using raw bmps (200 fps.) Huffyuv cuts down the size about 6x for me with 2.2.0 (from raw bmp to avi) I just cant get it to make a finished result viewable by any program (vlc, vegas 9.0, videomach, vdub, zoom player)

[aedipuss]

the only thing i can think of in huffyuv that you might have to do is check the box - "Always suggest RGB".

you don't say what size the bmps are. huffyuv is designed for sd material - 720x480.

[liquidr0x]

ive tried that...the bmps are 800x600 but im thinking about changing the bmp capture size to 960x540 (easy to get 25mb/minute), maybe ill try 720x480

what i don't understand is why i cant render in 24 or 32 bit color (vdub says the supported color depths are 24,32) so this is confusing to me

edit: 24/32 bit color gives me 3x less file size then 4:2:2 and i remember this worked for me in 32 bit windows

[aedipuss]

you have vegas, why not just use it with the bmps and render to whatever you want for a final format?

[jagabo]

In VirtualDub select Video -> Color Depth... Set the Output Format to 4:2:2 YCbCr (YUY2).

[liquidr0x]

i dont believe its possible to create avis from raw bmps in vegas...and i wouldn't do it this way anyway

jajabo...so are you saying this is the only way to go? I cannot render 24 or 32 bit with huffyuv? only 4:2:2?

[aedipuss]

i prefer pp to vegas for making avis out of stills but it should work. in options/preferences/video set the time length of a still to 0.02 and make sure that automatic overlap is unchecked. then import your bmps to the timeline.

[jagabo]

You can do 24 bit RGB too if you want. But I think there is some confusion between different HuffYUV decoders on that point. I only use version 2.1.1 which seems to have less compatibility problems. I never say any difference in compression ratios with 2.11 vs 2.2.0 when compressing the same sources in the same colorspace. Keep in mind that the amount of compression you get in HuffYUV depends a lot on the nature of the source.

In most cases you'll eventually be going to a YV12 colorspace (MPEG 2, Xvid, h.264, etc.) so using HuffYUV in YUY2 mode isn't really an issue.

[aedipuss]

crap, sorry my math skills are rusty, in vegas the time for a still should be 0.005 so that 200 of them are one second. that would give it 200fps.

[poisondeathray]

1) Do you really need 200fps ? Why not something more sane, like 60fps ? If you have I/O bottleneck or slower system, you might have frame drops and playback issues

24/32 bit color gives me 3x less file size then 4:2:2

I think you're mixing up chroma subsampling and color depth

http://en.wikipedia.org/wiki/Color_depth
http://en.wikipedia.org/wiki/Chroma_subsampling

2) For color depth, the difference between 24bit and 32bit is alpha channel, which you probably don't need if this is a video game capture. 32bit = 8 bits per component (8red + 8blue + 8green + 8alpha). Encoding that extra alpha channel requires more bitrate, even when it's encoded at a dummy alpha

3) Your original .bmp's are probably RGB (4:4:4 , no subsampling) , so you are losing color information by subsampling to 4:2:2, and incurring colorspace losses from RGB=>YUV. The subsampling is where a lot of the compression benefit is derived from. The bandwidth is ~1/3 of the 4:4:4 version, which may be where your're getting the 3x size from (maybe you inadvertently set it to RGB mode)

Our eyes are much more sensitive to luma than chroma. Jagabo did a nice post with pictures detailing what you're losing by subsampling to 4:2:2 and 4:2:0, but I can't find it offhand. There are some screenshots in the chroma subsampling link on wikipedia too

For CGI , and video game type source material, the difference with subsampling with respect to perception is usually greater than when the source material is normal "live action" material. This is because lines and borders between colors are usually more distinct

[jagabo]

3) Your original .bmp's are probably RGB (4:4:4 , no subsampling) , so you are losing color information by subsampling to 4:2:2, and incurring colorspace losses from RGB=>YUV. The subsampling is where a lot of the compression benefit is derived from. The bandwidth is ~1/3 of the 4:4:4 version

The bandwidth of YUV 4:2:2 is 2/3 that of RGB 4:4:4 (12 bits or RGB become 8 bits of YUV). In addition to that 1/3 off the top, I find HuffYUV usually compresses YUV 4:2:2 better than RGB 4:4:4.

[liquidr0x]

thanks for the feedback guys..i wasnt aware you could process raw frames in vegas ill mess around with this later

@poisondeathray - i am using 200 fps in case i want to slow down playback (i think i'm going to scratch this and go with 120 or 90 tho and save some space)

i am using this guide if anyone is interested in getting some more insight...skip the parts about HLAE effects..its pretty short anyways

http://www.pgl.ro/forum/threads/46713-MM-Folder.?p=962185#post962185 (scroll up to part 1 in english)

some more questions tho:

the raw bitmaps are captured in 32bit color (i can also choose 24 or 16), and i can choose bmp or tga to capture in.
the guide calls for 32 bit capture, in bmps...as for telling if they are 4:4:4 im not sure if they are.


so poisondeathray how should i render this? huffy doesn't support 4:4:4 as output (unable to initialize output codec..check that the video codec is compatible with the output frame size and the settings are correct) should i just go with 4:2:2? i read your post but im still a little confused on what to do as i'm not that knowledgeable on this stuff.

[poisondeathray]

3) Your original .bmp's are probably RGB (4:4:4 , no subsampling) , so you are losing color information by subsampling to 4:2:2, and incurring colorspace losses from RGB=>YUV. The subsampling is where a lot of the compression benefit is derived from. The bandwidth is ~1/3 of the 4:4:4 version

The bandwidth of YUV 4:2:2 is 2/3 that of RGB 4:4:4 (12 bits or RGB become 8 bits of YUV). In addition to that 1/3 off the top, I find HuffYUV usually compresses YUV 4:2:2 better than RGB 4:4:4.

thx for correction

To calculate required bandwidth factor relative to 4:4:4 (or 4:4:4:4), one needs to sum all the factors and divide the result by 12 (or 16, if alpha is present)

(4+2+2)/12 = 2/3 , not 1/3. My math sux I guess that would be 1/3 savings

[poisondeathray]

@poisondeathray - i am using 200 fps in case i want to slow down playback (i think i'm going to scratch this and go with 120 or 90 tho and save some space)

But what is your actual FPS in the gameplay? Have you measured it (e.g. in fraps) ? If you aren't getting 200fps actual gameplay, you will only get duplicated frames (= useless). Many video games are capped for upper FPS

But I agree a higher FPS is critical for high quality slow-mo later

the raw bitmaps are captured in 32bit color (i can also choose 24 or 16), and i can choose bmp or tga to capture in.
the guide calls for 32 bit capture, in bmps...as for telling if they are 4:4:4 im not sure if they are.

32bit per channel? or 32bit total? There is a HUGE difference. Standard .bmp are 8bpp (bits per pixel or channel) or 8x3 = 24 total

so poisondeathray how should i render this? huffy doesn't support 4:4:4 as output (unable to initialize output codec..check that the video codec is compatible with the output frame size and the settings are correct) should i just go with 4:2:2? i read your post but im still a little confused on what to do as i'm not that knowledgeable on this stuff.

What is your goal here? Most people would encode to a viewable standard format, like h.264. Filesizes are a lot smaller, and even though it samples 4:2:0, the quality loss is negligible for most people, if given adequate bitrate when viewed at normal speed. If you "pixel peep" most of the losses will be from the subsampling and colorspace conversion.

huffy doesn't support 4:4:4 as output

It does in RGB mode.

You might be having 64-bit issues as well, is all your software 64-bit ? I'm not even sure if there is a 64-bit build of huffyuv

[liquidr0x]

standard ingame gameplay is 100 fps, but hlae allows for any fps you want to capture (you set this in the config before you record your movie (mirv_movie_fps xxx)

im gonna guess and say 32 bits total for the bmps? the option is under "color depth" there is also an option to "force 8-bit alpha channel" - the guide calls to leave this unchecked


the goal is to produce a final render in x264

[poisondeathray]

If your gameplay is 100fps, it makes sense to capture at 100fps, not 200fps. This is waste of CPU and HDD space (2x the size, and you get dupe frames)

If you're capturing in .bmp, why not convert directly to h.264 using x264? or are you doing stuff in between like editing? If you're editing, what apps are you using to edit?
EDIT: whoops I see you are using vegas. Why not import the .bmp's into vegas as an image sequence as aedipuss suggested? You can encode using x264 directly using x264vfw, or debugmode frameserver to x264CLI (or other gui) in 8-bit project mode


I think some of your playback/decoding problems might be 64-bit vs. 32-bit related. Most of the time, in order for software to "handshake" , everything has to be the same. E.g. if you are using vdub 64 bit, you would probably need huffyuv 64-bit. For most video software, 32-bit still seems a lot more stable (although inroads are being made for 64-bit compatiblity)

[liquidr0x]

i see... as for the fps, 100 is what most people play ingame...but using HLAE the mirv_movie_fps sets the fps to capture at. I understand where you are coming from but generally you want to keep the fps at a multiple of 30 (30,60,90 etc.) so it is easy to scale down to the final 30fps of the final render in x264

as for the 64 bit i am running a 64 bit processor but i am using 32 bit vdub and 32 bit huffyuv (2.2.0). I have tried the 64bit huffy but it gives me similarly large filesizes to that of 2.1.1


as for the x264 im gonna follow the guide because i dont really know much about this stuff and final render with avisynth

[liquidr0x]

so basically i need to know if 4:2:2 is my only rendering option (seems to be the only one that works with bmps)

will capturing in .tga give me more rendering options?

[poisondeathray]

I understand where you are coming from but generally you want to keep the fps at a multiple of 30 (30,60,90 etc.) so it is easy to scale down to the final 30fps of the final render in x264

If your end goal is 30fps, then yes, an even multiple is nice. 200fps isn't an even multiple of 30fps
I assume this is for web? 30fps isn't compliant for blu-ray, for example (not without fake interlace mode)

so basically i need to know if 4:2:2 is my only rendering option (seems to be the only one that works with bmps)

I just did a quick test, and huffyuv in RGB mode works fine for me, from a bitmap sequence in vdub



I'm not sure why you're using huffyuv ? It's an extra step, and if you use 4:2:2 yuv, you lose quality from several colorspace conversions if you go in/out of vegas (vegas will convert to RGB internally, and you will convert back to YV12 when you do your final render - all these colorspace conversions are lossy)

With avisynth you can input your .bmp directly to x264 . I'm assuming you're using huffyuv for an intermediate edit, but you can open your image sequence directly in vegas without the extra step

There are other lossless codecs, you could use ut video codec in RGB mode, for example. It has an x86 and x64 installer

[aedipuss]

i see... as for the fps, 100 is what most people play ingame...but using HLAE the mirv_movie_fps sets the fps to capture at. I understand where you are coming from but generally you want to keep the fps at a multiple of 30 (30,60,90 etc.) so it is easy to scale down to the final 30fps of the final render in x264

ok, but 200 isn't a multiple of 30 either...

[jagabo]

Lagarith is lossless, compresses better than HuffYUV, and works in RGBA, RGB, YUY2, and YV12. It's slower than HuffYUV though.

I just removed HuffYUV 2.1.1 and installed 2.2.0. The RGB mode seems to be borked. It produces files ~1/3 the size (compared to 2.1.1) but no program can open them. They all crash and die. YUY2 mode works fine and produces slightly smaller files than 2.1.1, but not as small as Lagarith.

[liquidr0x]

the 200 fps figure came from the 40fps multiplier because i wanted too see if 40 fps was noticably better looking than 30 fps, dont rip me apart too badly guys :P (scratching this and capturing 120 fps)

as for opening stills in vegas when i highlight them all and try to move them into the video timeline vegas locks up for about 30 seconds and i cant get the stills to playback (no worries tho i am just going to use vdub for this)

at the moment i am messing with lagarith and msu loseless codec (i cant get utvideo to show up in vdub tho)

output with lagarith isn't playing back smoothly in media player classic in any rgb mode, but 4:2:2 plays back smoothly. Is this becasue the video is raw and has playback issues? (4:2:2 video is also about 25% smaller, not a concern though i am just trying to get the best quality i can) But as you posted i should try to keep my video RGB, so what do you guys recommend the color depth output to be (should i keep it 32 bit to display? and whats the deal with the decompression format, does this matter?)

available settings for color depth in vdub -- http://i49.tinypic.com/2s9vk0n.jpg

[poisondeathray]

as for opening stills in vegas when i highlight them all and try to move them into the video timeline vegas locks up for about 30 seconds and i cant get the stills to playback (no worries tho i am just going to use vdub for this)

In vegas, import as image sequence, not as individual stills. When you highlight 0001.bmp (or whatever the 1st image is) , the open dialog box will have a checkmark box at the bottom : "open still image sequence"

at the moment i am messing with lagarith and msu loseless codec (i cant get utvideo to show up in vdub tho)

For UT, make sure you use the correct installer. x86 for x86 and x64 for x64.

output with lagarith isn't playing back smoothly in media player classic in any rgb mode, but 4:2:2 plays back smoothly. Is this becasue the video is raw and has playback issues? (4:2:2 video is also about 25% smaller, not a concern though i am just trying to get the best quality i can) But as you posted i should try to keep my video RGB, so what do you guys recommend the color depth output to be (should i keep it 32 bit to display? and whats the deal with the decompression format, does this matter?)

Because lagarith is more compressed than huffyuv, realtime playback usually isn't possible. Huffyuv is less compressed and faster. UT is even faster but similar compression to huffyuv. You have to set up the #cores in the configuration correctly

It depends on where you are doing your editing. If it's going to be vegas leave it all 24bit RGB 4:4:4. The extra 8bits in 32bit mode aren't necessary (they are just for transparency). A RGB file will be about 25% smaller than RGBA file, depending on how well the alpha channel is compressed. You're not even using the alpha channel, so it's a waste of HDD space, and harder to playback (higher bitrates).

If you're not editing, skip all the steps and convert using avisynth and x264 directly. You can use ImageSource() to load your .bmps, and use ConvertToYV12() in the script

Your configuration for vdub in that screenshot is fine, if you are encoding to RGB.

Another option you might want to look at is fraps for capturing. It has a lossless mode as well now, and you can open the AVI directly in vdub, or vegas, or any other NLE.

[liquidr0x]

well now you just confused me a little :P

Yes, i am editing in vegas but you say to encode in 4:4:4 in vdub? or the setting i had in the screen shot above? (24bit RGB)

as for the utcodec i installed the right version for my os (x64) but if you say lagarith has better compression ill just stick with that and skip troubleshooting this codec.

[poisondeathray]

I'm not trying to confuse you. This post is just to warn you about vegas.

lagarith is lossless, but vegas (and most NLE's) don't necessarily treat them as lossless. They do a slight levels conversion, and you may see the brightness and colors shift a bit. Moreover, depending on the input, project settings and export settings, you won't get what you see in the preview monitor. The only way to allow passthrough is to use uncompressed, but even then the preview monitor isn't what you actually get. There is a disconnect between the preview monitor and what vegas "sees" internally. The only way to get accuracy (eg. if you're color correcting) is to use an external calibrated broadcast monitor

Each editor has little quirks, and this is one of vegas' many quirks

In vegas, if you import .bmp, and use 32-bit linear gamma mode, and export .bmp (or .png or other image sequence), there will be no shift. (although the preview will still be inaccurate)

There are 1000's of other combinations that cause little shifts. If you want to read about some of these quirks. If you search , you'll find many users complaining about "gamma shifts" and "washed out pictures". Well, this is the technical reason why.

http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm
http://www.glennchan.info/articles/vegas/colorspaces/colorspaces.html

I just wanted to give you a "heads up" with the problems you're going to be encountering. If you're not too picky, you might not even notice the difference

I *strongly* urge you to go through a mini workflow, where you just process maybe a 20sec clip from start to finish, instead of wasting time on a whole project only to find out later some settings were wrong...

[liquidr0x]

thanks for the warning....this is not going to be too much of an issue for me as i am going to be applying a lot of overlay/glow settings to my clips to get the best color out of each map (each map is different, some maps are darker/lighter and use different color sets)

as for the mini project this is a must...im gonna start a clip now and eventually render it to x264 and see how it looks ill post the clip when its finished

thanks for all the help!

[djonsson]

Using 9.10 on Ubuntu

On some of the images I render with KdenLive or OpenShot using Huffy lossless profile,
I get a pattern 35-50 pixels wide occuring at the bottom of the frame.

What is odd is some image sequences don't have this pattern and some do.

Can anyone help me define or resolve this problem.

[poisondeathray]

Using 9.10 on Ubuntu

On some of the images I render with KdenLive or OpenShot using Huffy lossless profile,
I get a pattern 35-50 pixels wide occuring at the bottom of the frame.

What is odd is some image sequences don't have this pattern and some do.

Can anyone help me define or resolve this problem.

I don't know why that is happening

You can try an alternative lossless codec, such as ffv1 or ut video codec . Both are available in ffmpeg so they should be available in kdenlive and openshot