Helix YV12 / I420 VFW Codecs

[karl_lillevold]

The Helix YUV Codecs are two almost identical Video for Windows compatible codecs for decompressing/viewing I420 and YV12 AVI files or the output of AviSynth scripts, as well as compressing/converting to these formats. A VFW codec is necessary for full viewing/editing support for a format in VirtualDub and other VFW applications.

Download: Helix YUV Codecs v1.2

Most of you will already have a VFW decompressor for YV12 via the XviD DLL, and for I420 via 'MS H.263' (msh263.drv). The problem with 'MS H.263' is that it does not handle anything not a multiple of 16, or larger than 352x288. The only restriction with the Helix YUV codecs is width must be a multiple of 4.

Neither XviD nor msh263 can convert to or "compress" to I420 or YV12 though, and it is convenient to be able to convert both to and from YV12 and I420, as well as have a native codec for both formats, always knowing which codec is responsible for handling the format, and knowing exactly how it is handled. And I also like to see 'YV12' or 'I420' as the format, when right clicking on AVI file, instead of 'XviD' or 'MS H.263', since it is the codec and not the 4CC code that is displayed.

What is I420? It is simply YV12 with the chroma planes swapped. Why I420? Probably not too common around here, but with it being the native input format for Helix Producer, I have always worked with I420 files.

Features

• Both decode I420 and YV12.
• Fast color conversions to all common RGB formats, YUY2, and of course I420 and YV12 when requested.
• i420vfw.dll encodes to I420, yv12vfw.dll encodes to YV12.
• Otherwise identical, both encoders accept common input formats, and losslessly converts to and from both color spaces, i.e. with "Fast recompress" in VirtualDub, there is no conversion via RGB.

Known issues

Width has to be a multiple of 4, and the height a multiple of 2.

Changelog
1.2 (10/09/03): Fixed problem with swapped U and V planes when saving to I420/YV12 from other formats than I420/YV12.
1.1a (7/30/03): Installer now removes pre-existing vidc.I420 or vidc.YV12 from HKEY_CURRENT_USER in case it is there. It should not be since HKEY_LOCAL_MACHINE is the common norm for VFW codecs, but Osprey, a capture card manufacturer, installs a problematic I420 VFW codec there, that will over-ride the Helix I420 codec unless removed.
1.1 (7/7/03): when used as compressors in VDubMod, the input format will now be YV12 from any codec capable of supplying this (instead of YUY2). No change in decompressors, and no need to update for most users.
1.0a (7/5/03): win9x support in installer. Also, uninstaller will now delete reg key vidc.i420/yv12 only if it points to one of the Helix DLLs.


Installation
The automatic installer simply copies the DLLs i420vfw.dll and yv12vfw.dll to the windows system directory, C:\windows\system32 in most cases, and registers the 4cc codes I420 and YV12 in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Drivers32 with vidc.i420 and vidc.yv12 set to i420vfw.dll and yv12vfw.dll. The installer asks which of the codecs you would like to install.

Hope you find these useful. If you try them, please let me know of any problems.

[phrentec]

would you recommend to use this for video capture? could you also give another scenario to use this in because i though the newer versions of helixproducer already supported I420 and YV12 as input or should this be used with Gabest's realmedia directshow filter if the realvideo is in I420. Also what happened to the rids3290.dll?

Thanks Karl.

[karl_lillevold]

Since most video capture devices support I420 output, but not YV12, I would recommend capturing to I420, for use as input to Producer. Then you can use these VFW codecs to view, edit, and convert losslessly the files you captured.

[Animaniac]

Thanks, these should be very useful!

[karl_lillevold]

Originally posted by phrentec
should this be used with Gabest's realmedia directshow filter if the realvideo is in I420. Also what happened to the rids3290.dll?

It's not really related to Gabest's RM DS filter.

rids3290.dll is now called dsreader.dll. Maybe I did not quite understand your question.. Helix producer still reads its source files via dshow on Windows, but it understands common YUV formats, like YV12, I420, YUY2 natively, so these VFW codecs are not used. Producer then simply tells dshow to provide the raw data without going via a decompressor.

I found good use for the I420 codec in particular when running some PSNR tests in Avisynth, because all my ITU test clips are in I420, and the I420 codec outputs YV12 when requested. Similarly, if you happen to have I420 files from capture or other sources, and want to compress to XviD or another codec that accepts YV12, just use "Fast recompress" in VirtualDub to avoid going via RGB.

[karl_lillevold]

i updated the version to 1.0a after making a couple of modifications to the installer script. No change to the codecs themselves.
o win9x support in installer, hopefully, not fully verified.
o uninstaller will delete reg keys vidc.i420/yv12 only if they point to these DLLs (in case they were changed to point to other codecs after installing these, they will not get deleted by the uninstaller)

I have one question perhaps someone here can answer. In VirtualDub and ..Mod for a YV12 source when I choose "Fast Recompress" and use a YV12 capable compressor like XviD or even the Helix YV12 codec, based on the FAQ on YV12, I would have expected VDub to ask the codec to provide YV12.. But I see in the debugger that VDub asks for YUY2, even though the Helix codecs say they support YV12. In fact VDub does not even ask for YV12, it asks for YUYV and YUY2 as far as I can tell. Is this expected? Maybe I should jump over to Avisynth Dev and ask there.

From FAQ: "Just load your avs file in Virtual Dub and set the video on "Fast recompress". In this mode the process will stay in YV12 (all the necessary filtering has to be done in AviSynth itself). Under compression select a codec which support YV12"

[sh0dan]

Correct Vdub asks for YUY2, whereas VdubMOD asks for YV12 before YUY2. I've asked Avery to correct this, but he doesn't seem to care...

Anyway Vdub doesn't have anything VDubMod doesn't have (except maybe a smaller installer ) - so I don't care that much.

[karl_lillevold]

You are right, but only for XviD. If I do YV12 -> YV12 (Helix), VDubMod asks for YUY2, if I do YV12 -> XviD, VDubMod asks for YV12. I will investigate some more. Either something is hard-coded in VDubMod to prefer YV12 for XviD, or my YV12 compressor is somehow not communicating well enough to VDubMod that it would really really like YV12 as input

[sh0dan]

I don't think anything special was made for XviD (as I made the first hack to allow YV12). The code is somewhere in Dup.cpp

(Search for YV12 - skip the overlay things - actually I don't know why vdubmod doesn't attempt YV12 overlay, but nevermind that).

Even though the comments state that it attempts "UYVY" first this isn't the case when you look at the actual code.

[karl_lillevold]

Thanks. That helped me find the problem in my code. With VDubMod, both the I420 and YV12 codecs now get YV12 input from any codec capable of supplying this (instead of YUY2), when they are used as compressors to I420 or YV12. There is no change when used as decompressors.

[karl_lillevold]

tiny tiny update. I found that on systems that have installed an Osprey capture card, Osprey is nice enough to include an I420 codec. However, it does not work very well (for instance, no YV12 support for Avisynth), and also, Osprey decided to put the vidc.i420 reg key in HKEY_CURRENT_USER and not along with all the other VFW codecs, in HKEY_LOCAL_MACHINE. So unless the key in HKCU is removed, the Osprey codec will be loaded before the Helix codec, and you are out of luck, causing a minor headache trying to figure out why for instance an Avisynth script referencing an I420 file can not provide YV12.

So the little update is to include in my installer, the removal of any I420 / YV12 vidc string value in HKCU, in case it is there, before placing a new vidc.I420/YV12 in HKLM.

p.s. a little warning for those that use YV12 support in ffdshow instead of a native VFW codec (like the Helix YUV codec) for YV12 playback. Having YV12 enabled in ffdshow causes Gabest's Directshow filter for RealMedia to malfunction.

[bobololo]

I've just installed these codecs and I get a little problem. I'm currently developping a VFW codec and I use vdub to debug.

Once I've installed these codecs, and run vdub through MSVC debugger, an assert failed. The debugger reports this message :

HEAP[VeedubP4.exe]: Heap block at 00150E90 modified at 0015108C past requested size of 1f4

This is a bit annoying since I can't debug my codec anymore When I uninstall the yuvcodec, the debugger works fine.

Do you have an idea of what is going ?

ps: I've installed 1.1a.

[karl_lillevold]

no, sorry, I have frequently run VDub myself in MSVC with these codecs without any asserts or problems. When is it you get the assert? Maybe I can try to repro your scenario.

[bobololo]

Originally posted by karl_lillevold
no, sorry, I have frequently run VDub myself in MSVC with these codecs without any asserts or problems. When is it you get the assert? Maybe I can try to repro your scenario.

I've investigated a little bit more and I discovered an interesting issue. Actually the assert has nothing to do with yuvcodecs. It occurs with any codec provided that the total number of registered codecs (vidc.xxxx in HKLM/.../Drivers32) is exactly equal to 24 ! Weird isn't it ?

The assert comes out when stepping over ICInfo() function call.

I've searched for some info from MS documentation and I found nothing.

[stevenxu]

It seems to save U block and V block in wrong order.

[karl_lillevold]

it's funny you should mention this right now, i just discovered the problem yesterday, and fixed it today. New version should be ready tomorrow. The error got introduced when I fixed the "fast recompress" option for I420->YV12 and YV12->I420, so those work fine, it's just saving ("compressing") to I420 and YV12 for any other format that's reversed.
Thanks!

[karl_lillevold]

corrected version posted (1.2). This problem shows how rarely the codecs are used as "compressors", even by myself No need to update unless you use these codecs to convert to YV12 or I420. Let me know of any other problems.

[trbarry]

Are there any speed or quality differences in the YV12->YUY2? Anybody notice any?

- Tom

[freelock7]

ince I have downloaded the helix codec I don't need to convert to RGB with Tmpgenc through aviscript.
What does it means?
Tmpgenc works better in YV12 space color??

[Wilbert]

Since I have downloaded the helix codec I don't need to convert to RGB with Tmpgenc through aviscript.

True.

It means that this codec converts your video to RGB when opening in TMPGEnc. The processing done by TMPGEnc is always in RGB.