Helix YV12 / I420 / IYUV VfW Codecs

[karl_lillevold]

The Helix YUV Codecs are three almost identical Video for Windows compatible
codecs for decoding and viewing of YV12, I420 and IYUV
AVI files or AviSynth scripts in all versions of Windows. Additionally, they will let
you convert/encode/save as.. to any of the three formats. When converting from
one YUV format to another it is a lossless conversion.


2016/12/14: New version Dec2016 by MLJ
Download: HelixRC3 (https://dl.dropboxusercontent.com/u/1226388/HelixRC3.7z)

Thanks again to MLJ for providing this update!

Here is the information provided in the package ReadThis.txt:

Helix YUV Codecs RC3 - Version 1.2/1.3 by Karl Lillevold
Release: December 2016

LEGAL DISCLAIMER:
Great Care and very Intensive Tests where made by developing this
Software before it was Released. This Software is "AS IS" and the
Author can not be made liable under any Circumstances for any
Damages or Data-Loss of any Kind by installing and using this
Software ! The End-User agrees to these Terms silently and uses
this Software on his own Risk by installing and using this
Software ! It is strictly forbidden to include and distribute the
Helix Codecs in so called "Codec-Packs" ! The Helix Codecs are NOT
FOR SALE or Re-Distribution of ANY Kind ! All Rights Reserved !

IMPORTANT WARNING !
DO NOT USE THE "VCSWAP" TOOL BECAUSE IT MESSES UP THE FOURCC TABLE
IN WINDOWS ! The "VCSwap" Tool changes all uppercase FourCC's to
lowercase but many Routines inside DirectX rely on uppercase
FourCC's and their Entries in the Registry to work properly.

Special thanks to:
Igor Pavlov - for the "7Zip" Freeware Program
Nicolas OTT - for NLE and Hardware tests (Win SE to 8 ,32/64 Bit)
Michael Henke - for Ingest Hardware and NLE tests
Mickey Lee Jones - for IYUV Development, Fixes and INF-Script

Helix YUV Codecs Features: (Fully Tested)
I420: YCbCr 12 Bit Planar YUV
IYUV: YCbCr 12 Bit Planar YUV (New)
YV12: YCbCr 12 Bit Planar Swapped YUV
Alpha Channel Support: Yes
RAW VBI Support: Yes
MMX CPU Support: Yes
SD / HD Support: Yes
DirectShow Support: Yes
ActiveMovie Support: Yes
Video for Windows Support: Yes
QuickTime for Windows Support: Yes (AVI with I420/IYUV)
AVI1 (VfW) Support: Yes
AVI2 (OpenDML) Support: Yes
Overlay Support: Yes
Multiple Overlay Support: Yes
Image Color Management (ICM) Support: Yes
Interlaced Support: Yes (All SD/HD TFF/BFF Field Orders)
Progressive Scan Support: Yes
Progressive Segmented Support: Yes
Alternating Scan Line Support: Yes
Supported Frame Rates: All
Supported Pixel Types: Square / Non-Square
Supported Television Norms: All ITU/EBU/ATSC/SMPTE Norms
Format Support for H.26x/MPEG-1/-2/-4: Yes
Format Support for FFMpeg: Yes
Format Support for FFDShow: Yes
Format Support for AviSynth: Yes
Format Support for AVC/AVCHD: Yes
Format Support for UHD and Cinema: 2K (V1.2), 2K/4K/8K (V1.3 only)
Support for Dual-Image 3D: Yes (V1.3 only)
Extended Buffering: V1.2 = No, V1.3 = Yes

System Requirements:
Microsoft Windows 9x to 10 (32/64 Bit)
Microsoft DirectX (Version 7,8,9 and higher recommended)
Microsoft Media Player 6,7,9 and higher
Apple QuickTime for Windows Version 4 to 7 and higher (Optional)
Intel/AMD Processor with MMX Support for best Performance
Intel/ATI/Matrox/NVidia Graphics Card with I420/IYUV/YV12 Support
The Freeware "7Zip" by Igor Pavlov to unpack the Files

Installation:
Save the downloaded File to a Location on your Harddisk and extract
the File with "7Zip". NOTE: DO NOT try to install the Codecs WITHOUT
extracting the Files to a Folder on your Harddisk !

IMPORTANT:
It is highly recommended to install Version 1.3 first. Version 1.2
should ONLY be used if you have a older System with a older Capture
Card or Video Device. Please DO NOT mix the Version 1.2 with Version
1.3 ! If you do want to try another Version, uninstall first before
you try a different Version of the Helix Codecs !

ATTENTION !
The Helix RC2 that only contained the original Helix Codecs without
the new IYUV Codec is no longer available !

Installation: (Windows 9x to 10, 32/64 Bit)
The Helix RC3 Codecs are available in two different Versions:
"HelixRC3.7z" -> contains the new Helix 1.2/1.3 Codecs

Helix Codec Version 1.2: Folder "Ver12\Helix12.inf"
Helix Codec Version 1.3: Folder "Ver13\Helix13.inf"

Simply right-click on the "Helix12.inf" OR "Helix13.inf" File
and follow the Instructions.

Windows NT to 10 Users need Admin Rights to Install the Codecs and
should read the Section "Troubleshooting" in this Document in case
the Installation fails on 64 Bit Systems.

Windows 9x to ME Users should restart the System after the
Installation completed and we highly recommend to use the "Infast"
for a silent or the "Infstall" Program for a guided installation.

If the Message Window "Uncertified Program" and/or "Unsigned Driver"
pops up, simply click on the "OK" Button to ignore the Message and
continue with the Installation.

After the Installation completed, open the "Run" Command, type
"dxdiag" and press the "OK" Button. DirectX Diagnostics will
register now the new Helix Codecs with the DirectX Engines.

Please note that the new INF-Script does NOT delete any other Codecs
on your System and only replaces them in the Registry. The replaced
Codecs are restored if the Helix Codecs are removed from the System
via the "Uninstall" Option (Software). Other third Party Codecs are
NOT restored, ONLY the native Windows Codecs !

Description:
The Helix YUV Codecs encode/decode I420, IYUV and YV12 RAW Format
Videos. Fast color conversions to all common RGB formats, YUY2,
and of course I420, IYUV and YV12 when requested.

"i420vfw.dll" encodes to I420 -> Replaces Microsoft msh263.drv (*)
"iyuvvfw.dll" encodes to IYUV -> Replaces Intel iyuv_32.dll
"yv12vfw.dll" encodes to YV12 -> Replaces XviD as a YV12 Decoder

(*) = Up to XP. Vista to 10 uses the modified Intel Iyuv_32.dll.

Otherwise identical, the 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.

Example for "Fast Recompress" in VirtualDub: (See Note !)
I420 can be converted losslessly to IYUV but NOT to YV12
IYUV can be converted losslessly to I420 and YV12
YV12 can be converted losslessly to I420 and IYUV

Note:
Using "Fast Recompress" with the Helix I420 Codec to the Helix YV12
Codec WILL SWAP THE PLANAR YUV and is meant to work this way !

The Reason are MPEG-1/2/4 encoders because many NLE's install
a Filter for the Color Conversion from I420 to YV12 so MPEG Videos
don't encode the inverted Chroma and is reversed by the additional
Filter if a Video with I420 is used. The same Filter is used during
capture, encoding or decoding MPEG-1, MPEG-2 and MPEG-4 Videos.

Solution 1: (Recommended)
Open your I420 Video with Nic's "FourCC Changer" by either draging
it to the field where the two dots are or press the Button with the
two dots and navigate to the location of your Video. Then change the
FourCC from "i420/I420" to "iyuv/IYUV" in both fields and press the
"Apply" Button. If both Entries are upper-case, then replace them both
as upper-case.

In the "FourCC Description Code" Field you should insert iyuv (lower
case) and in the "FourCC Used Codec" Field IYUV (upper case) because
ActiveMovie uses lower case FourCC while DirectShow uses the upper
case FourCC to identify the Codec. This only changes the FourCC code
without re-rendering the Video and can be changed back to I420 anytime
when requested.

CAUTION !
Changing the FourCC from I420/IYUV to YV12 WILL SWAP THE YUV PLANES !

Solution 2: (Best alternative)
Open your I420 Video in VirtualDub, select the Box "Ask for extended
options after this dialog" before you press the "OK" Button and enable
the Options "Force video format FOURCC code to", insert iyuv (lower
case) in the "Force video codec handler FOURCC code to" insert IYUV
(upper case) and click on the "OK" Button. Your I420 Video is now
loaded with the IYUV Codec in VirtualDub.

This has the same effect as using Nic's FourCC Changer, only that the
FourCC code I420 is mapped to IYUV and not permanently changed.

Solution 3: (not recommended)
Open your I420 Video in VirtualDub and select the Mode
"Normal Recompress" and change the Colorspace to YUY2 or YV12 in
the "Video - Color Depth" Option.

All Solutions will prevent a Swap in the Planar YUV Colorspace.

The Helix Codecs negotiate with other Codecs in this Order:
I420 (12 Bit) -> I420 12 Bit/YUY2 16 Bit/RGB24 24 Bit/RGB32 32 Bit
IYUV (12 Bit) -> IYUV 12 Bit/YUY2 16 Bit/RGB24 24 Bit/RGB32 32 Bit
YV12 (12 Bit) -> YV12 12 Bit/YUY2 16 Bit/RGB24 24 Bit/RGB32 32 Bit

If a target Codec is able to compress I420/IYUV/YV12 then the
Source Colorspace (FourCC) is not changed and remains lossless if
"Fast recompress" is used in VirtualDub otherwise YUY2 or RGB24.

Input for the Helix Codecs can be:
YVU9 / YUY2 / RGB24 / RGB32 and UYVY -> See Note !

Note:
UYVY is always mapped to RGB24 and is the default behavior of
DirectX and their Components. That's why many Capture Cards and
Devices only offer I420 and YUY2 as the default Color Space to
prevent the mapping over RGB24 while the I420 Color Space is
directly used by the Hardware.

AviSynth 2.5.x:
A "DirectShow" Script uses these Color Spaces:
Helix I420 is decoded as YUY2 -> see Note
Helix IYUV is decoded as RGB32 -> see Note
Helix YV12 is decoded as YV12

Note:
This is meant to work this Way and conforms to the DirectX Specs.

A "AviSource" Script uses these Color Spaces:
Helix I420 is decoded as YV12 -> see Note
Helix IYUV is decoded as YV12 -> see Note
Helix YV12 is decoded as YV12

Note:
The YUV Planes are properly swapped without any Chroma Shifts.

Hint: (VirtualDub Versions 1.6 to 1.10)
Disable the Option "Directly decode uncompressed YCbCr Sources"
under "Options - Preferences - AVI" in VirtualDub. This disables
the internal YUV Codecs in VirtualDub and the external ones are
used instead. Disable the "Allow Video Overlays" Option if you
see a "Green Screen" during Playback or encoding in VirtualDub.

Videos encoded with the Helix I420/IYUV Codecs can be played back
in Apple QuickTime for Windows (YUV420). Videos encoded with
VirtualDub in YV12 can be decoded with the Helix Codecs. AviSynth
uses the Helix YV12 Codec instead of the XviD Decoder.

Limitations: (Windows 9x to XP)
The Intel IYUV Codec (I420/IYUV) is limited to 640x480, max.30 Fps.
Videos encoded with the Helix Codec in this Resolution can now be
decoded by the Intel Codec and vice versa. Means, a Video encoded
with the Intel I420/IYUV Codec (iyuv_32.dll) can now be decoded with
the Helix Codecs and Videos using the Intel 4:2:0 Codec (msh263.drv)
or Intel RAW 4:2:0 (i263_32.drv) can also be decoded with the Helix
Codec.

Drastic YCbCr I420/IYUV/YV12 Videos can now be encoded/decoded both
Ways at higher Resolutions and Frame Rates. (Fully Tested)

Overview:
Intel 4:2:0 (I420) -> can be decoded using the Helix 32 Bit Codec
Intel RAW 4:2:0 -> can be decoded using the Helix 32 Bit Codecs
Intel I420/IYUV -> can be decoded using the Helix 32 Bit Codecs
Drastic I420/IYUV/YV12 -> can be used both Ways
Helix I420/IYUV -> can be decoded with the Intel 32/64 Bit Codecs at
a maximum Resolution of 640x480 at max. 30 Fps. Larger Resolutions
and Frame Rates are NOT supported by the Intel Codecs !

The Helix Codecs are only avaliable in 32 Bit Applications on 64 Bit
Systems and is meant this Way. The 64 Bit Intel Codecs will show up
in the List of available Codecs instead of the Helix 32 Bit Codecs
with 64 Bit Applications.

Important:
The Helix Codecs are RAW Codecs and don't vary in the Bitrate. A
large Resolution with a high Frame Rate results in a higher Bitrate
and vice versa. Most Consumer Devices are limited to VGA if the User
selects I420/IYUV/YV12 to capture a Video (640x480) because Windows
does not support natively higher Resolutions using these FourCC's.

The Helix Codecs can be used to compress higher Resolutions that are
available through YUY2 by the Capture Card or Device via VirtualDub
or other Capture Software where the target Codec is selectable.

[...]

WARNING !
DO NOT RUN THE 64 BIT REG-FILE ON A 32 BIT SYSTEM AND VICE VERSA !

Windows 9x Users need to edit the "System.ini" File. Open this File
with "NotePad" (Editor) and change the following Section:

[Drivers32]
VIDC.I420=i420vfw.dll
VIDC.IYUV=iyuvvfw.dll
VIDC.YV12=yv12vfw.dll

Save the edited System.ini File and navigate to the Folder where you
uncompressed the Helix Codecs. Look for the "Helix9x.reg" File and
double-click on it. A Window pops up and click on the "OK" Button to
add the ICM Descriptions to the Registry.

Note:
The "VIDC.IYUV=iyuvvfw.dll" Entry is ONLY available with the Helix
Codec Version 1.2/1.3 RC3, NOT with Version 1.2/1.3 RC2 which is no
longer available !

Close all Applications and restart your System to re-enable the
Helix Codecs.

Uninstall:
Open the "Software" Applet in Windows, select the "Helix Codecs"
and click on the "Remove" Button. This removes the Helix Codecs
and restores the Registry and native 32 Bit Windows Codecs.

Users with Windows 9x/SE/ME need to restart the System.

After you uninstalled the Helix Codecs, open the "Run" Command,
type "dxdiag" and press the "OK" Button. The DirectX Diagtool now
re-registers the native Windows Codecs for the DirectX Engine.

Known Issues:
Width has to be a multiple of 4 and the Height a multiple of 2.
Recommened for best Performance: 4x4

The new Installation Routine always installs all Helix Codecs
and they can not be selected individually anymore to enable a
lossless Transcoding from one Colorspace to another.

The Helix Codecs can not be selected in some Ulead/Corel Software
Versions for Compression, only for De-Compression when you captured
with I420 or YV12. This is a Issue in some Ulead/Corel Versions and
not a Bug in the Helix Codecs.

Videos encoded with the Intel IYUV Codec can now be played back
with the Helix Codecs even if the Intel IYUV Codec converts 12 Bit
up to 24 Bit and vice versa while the Helix Codecs stay in 12 Bit.

VirtualDub does not support I420/IYUV as a Output Format. If the
"Normal Recompress" or "Full Processing" Modes are used then the
Conversion is made over RGB. "Direct Stream Copy" is without any
Conversion, just like the "Fast Recompress" Mode.


Blue-Screen with large Resolutions using RGB32
Karl Lillevold:

7th August 2015
"forclip" informed me that if using a renderer with RGB32 output, for
example VMR-9, for higher than HD resolutions (e.g. 2560x1440) the
Helix YV12 converter will cause a crash. I investigated this and found
that when I created version 1.3 and allowed up to 8192x8192, I failed to
notice that the assembly coded YUV to RGB color converters written in
1996 are hard-coded with a 2080 pixel wide limit. Back then no one
foresaw resolutions would ever need to be higher :S

All I can do at the moment is add this information to the thread, as I
am unable to make any modifications to the assembly code, nor in fact
build the projects due to build system incompatibilities. If staying in
the YUV domain, the converters work fine up to 8192.


Other product names, trademarks and registered trademarks mentioned
in this Document are the property of their respective holders.
-EoF-

For a Changelog, see ReadThis.txt in archive.

[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 (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/virtualdubmod/VirtualDubMod15/VirtualDub/source/Dub.cpp?rev=1.25&content-type=text/vnd.viewcvs-markup)

(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 (http://forum.doom9.org/showthread.php?s=&threadid=56940) 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 (http://www.lillevold.com/files/yuvcodecs-1.2.exe)). 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.

[freelock7]

I see.
But Tmpgenc seems to work better with this codec (faster).
Helix is it able to perform a better color conversion in RGB than another codec?

[t_2]

Wow, this is great. Already found a use for it. Elsewhere in this forum found the following link where a sample video can be downloaded.

http://www.geocities.com/alex_j_jordan/

When I tried to open it with the latest Xvid codec I got a mess after the first frame, after installing ffvfw and turning off Xvid with vswap, I got the message that no YV12 decoder could be found on the computer so installed Helix YV12, set ffvfw to decode DivX and no more problems. Thanks! I have already run into several decoding problems with the latest Xvid (It even has trouble decoding at least one earlier build of Xvid) so this new Codec is great!

[Wilbert]

set ffvfw to decode DivX and no more problems.
I guess you mean "Helix YV12" instead of DivX?

[t_2]

@Wilbert

I have a real neat Radix PCI protector card on this computer which allows me to experiment a lot without ruining my system, so everytime I log on I have to install AviSynth, Xvid, etc. It just takes a minute and I highly reccommend it, because many of these media codecs are very stuborn when it comes to removing them.

Anyway, the only MPEG4 decoder I had on my system was Xvid. The file I wanted to open was DivX. Xvid opened it in VirtualDub but after the first frame it was a mess. So I installed ffvfw and set it to decode DivX, but after turning Xvid off ( in Vswap) I could no longer open the file because ffvfw evidently couldn't decode the YVI2, but after installing the Helix codec not only could I open it with ffvfw, but that codec did a good job of decoding the MPEG4.

I didn't realize ffvfw could be set to decode Helix YV12, or maybe I just don't understand your question and what you are trying to point out. Please clarify, Thanks.

t_2

[Wilbert]

I though you used DivX to decode that chroma.avi. Sorry, I misunderstood what you were saying.

Btw, DivX5 decodes it also correctly.

[Alain2]

What about Helix codec 1.2 (http://forum.doom9.org/showthread.php?s=&threadid=56972) ? Don't know if it handles interlaced video thoughI am afraid this codec support YV12 in non uncompressed way,
or I recall badly....
Can you confirm wether the helix YV12 codec 1.2, when used with vdubmod to compress to yv12, is lossless or not? I was using it for avs script treatment before my 3 x264 passes encoding thinking it was lossless, but Poutnik comment makes me wonder...

Thanks

[ariga]

I was using it for avs script treatment before my 3 x264 passes encoding thinking it was lossless, but Poutnik comment makes me wonder...
You are confused.

The "Compression..." setting in VDub determines which codec to use. How much compression really happens and the type of compression depends on the codec you choose. The codec may decide to throw away some information to reduce the size (lossy compressed), retain all information and still reduce the size (lossless compressed) or store all the information as is (lossless uncompressed).

[Wilbert]

I guess you are confused. First it compresses. Second, i don't know whether it is lossless or not. Karl doesn't say anything about it in his announcement post. I guess best is to send him a pm to find out.

edit: reading Leak's response in the other thread, i see i'm wrong here. Sorry about that. It looks like it's just a colorspace converter.

[karl_lillevold]

It is not really a "compressor". It is a color convertor. If you choose "Fast recompress" in VdubMod, and the input format is a 'YUV' format, it is lossless, i.e. the conversion does not go via RGB. If you choose "Normal recompress" for "Full Processing mode", the input will be RGB, and the conversion will not be completely lossless, in the sense of rounding errors.

In general though, after I discovered Avisynth a few years ago, I rarely use these codecs to convert to YV12 or I420. Instead I use Avisynth directly.

Alain2: why do you use it to convert (compress) to YV12?

[Alain2]

Well it's not that I am really confused, it's just that I didn't know all that ^^ The idea was : I have an avs script which takes hours to compile (there is some deen, fft3dfilter, dehalo_alpha in it), so the idea was to do a lossless uncompressed pass of this script, and then compress the result with 3-pass x264, that way I use the script only once instead of the 3 passes, so it speeds up things on particularly long scripts.

YV12 because my avisynth script is outputting YV12, so for the lossless temp clip I wanted to keep the same format. But i didn't know the trick of fast recompress versus normal / full processing. I never use vdub, i decided to use it only a few days ago to do my lossless yv12 clip, but I made the mistake of choosing full processing... Does the same apply for the other lossless codecs that are mentionned in ariga's thread (http://forum.doom9.org/showthread.php?t=103357)?

If you know of a better way for me to do an uncompressed lossless clip out of an avisynth yv12 clip, please shoot ;)

btw i checked, i have lost a lot between my avs output and the yv12 raw file obtained with the full processing parameter :( so as this Helix codec can do lossless only for yuy format, i need to use another codec for yv12 -> yv12 lossless, like ffdshow ? The name "yuv-codecs-1.2.exe" somehow confused me, probably because i didn't know about yuv format ^^

[karl_lillevold]

Why don't you just use Vdubmod "Direct Stream Copy"? The output of Avisynth will then be YV12. No need to use the YV12 compressor at all.

And you are right: in Full Processing Mode, Vdubmod will convert YV12 to RGB and feed that to the YV12 compressor, which will then convert RGB back to YV12. This is not lossless. So use Direct Stream Copy; and you don't need the YV12 compressor...

[Alain2]

I think sometimes I miss the obvious ^^ Thank you Karl :)

[smokeslikeapoet]

What is the licensing of these codecs? Free, Free for non-commercial use, or open source? I don't need the source but I'd like to be sure that I can install them on a computer at work.

[rig_veda]

If Helix codec 1.2 is used in VirtualDubMod for opening avisynth scripts, there seems to be a bug if width is only a multiple of 4: The image is slightly darker. This doesn't happen for multiples of 8 or 16.

[karl_lillevold]

What is the licensing of these codecs? Free, Free for non-commercial use, or open source? I don't need the source but I'd like to be sure that I can install them on a computer at work.
Free for all kinds of use, but not open source.

[karl_lillevold]

If Helix codec 1.2 is used in VirtualDubMod for opening avisynth scripts, there seems to be a bug if width is only a multiple of 4: The image is slightly darker. This doesn't happen for multiples of 8 or 16.
Very strange. I can not reproduce it though. I opened two scripts side-by-side, both referencing the same source AVI, one 352x288, one resized to 348x284. I could not see any difference.

[rig_veda]

Very strange. I can not reproduce it though. I opened two scripts side-by-side, both referencing the same source AVI, one 352x288, one resized to 348x284. I could not see any difference.

I could observe it via

mpeg2source("Laputa.d2v")
TFM(PP=0,display=false,input="Laputa_auto_TFM.txt")
TDecimate(noblend=true,input="Laputa_auto_TDecimate.txt")
Lanczos4Resize(860,484)
Crop(24,8,-24,-12)

versus

mpeg2source("Laputa.d2v")
TFM(PP=0,display=false,input="Laputa_auto_TFM.txt")
TDecimate(noblend=true,input="Laputa_auto_TDecimate.txt")
Lanczos4Resize(860,484)
Crop(26,8,-26,-12)

when i placed two instances of VdubMod on top of each other and switched between those windows via taskbar. I don't know if it's noticable when the windows are next to each other, since it's only a small difference, but it's noticable. I made screenshots and checked the diff in paint shop: it's around 2-4 in each of the 3 color channels; It's present in the whole image, and it's influenced by the image, so it might be rounding errors, but why and of what? Is there a different calculation going on in one of the cases or VdubMod accessing helix differently? Pretty weird. o_O

[karl_lillevold]

So what I tried next was the following:
Video 1:
Rawsource("foremn_c.yuv",352,288,"I420").AssumeFPS(30.0).Crop(2,2,-2,-2)
resulting in 348x284 video. I saved 10 frames, using Direct Stream Copy. Then I added back borders:
AVISource("f_crop.avi").AddBorders(2,2,2,2)
Again saved using Direct Stream Copy.

Then I compared this with the original video, and the only pixels that differed, were the ones within the 2 pixel border around the edge.

[rig_veda]

So what I tried next was the following:
Video 1:
Rawsource("foremn_c.yuv",352,288,"I420").AssumeFPS(30.0).Crop(2,2,-2,-2)
resulting in 348x284 video. I saved 10 frames, using Direct Stream Copy. Then I added back borders:
AVISource("f_crop.avi").AddBorders(2,2,2,2)
Again saved using Direct Stream Copy.

Then I compared this with the original video, and the only pixels that differed, were the ones within the 2 pixel border around the edge.

Did some tests got the same result here, too. The final video looks identical to the original source in VdubMod, so nothing gets changed on the encoding/decoding side. But when I fed it cropped source without restoring the borders to give it it's original width back, it still looked darker though, so i guess the presumed bug must be in the YV12->RGB conversion for preview section of VdubMod. Fast recompress or direct stream copy isn't affected, but according to my tests full processing is. Anyway, this is the wrong thread for this, i'm heading over to VdubMod. :)

[manolito]

However, one possibility to feed YV12 directly into CCE is some external codec that decodes YV12 data for it. This seems to work reliably only with CCE-SP 2.67.00.10 and newer, both DivX and XviD should do the job, as well as the lite version of the ffvfw codec included in the latest AVISynth 2.5 installers. In my tests however (using the ffvfw codec) and others, there seems to be not any difference in speed or even decreased speed compared to a ConvertToYUY2() in AVISynth. Also, the externals codecs may assume progressive video (at least DivX and XviD do) and mess up chroma for interlaced video for reasons outlined above. So for the time being, my advice is to stick to the conversion in AVISynth, eliminating another source for possible problems by minimizing the number of video processors involved.
This is from the CCE FAQ, and up to now I used the ConvertToYUY2() command in AviSynth. But recently I noticed that I do get a slightly better speed when I let the Helix codec do the conversion.
Question: Does the Helix codec handle interlaced content correctly, or will it also mess up chroma like DivX and XviD?

Cheers
manolito

[Boulder]

AFAIK Helix assumes progressive content.

[smokeslikeapoet]

manolito: I think I can answer your question about interlaced content. Helix works on ATSC DVB-T 1080i content nicely. The Xvid and Divx YV12 decoding turns people pink. The Helix decoder looks natural, I'm pretty sure this is a colorspace issue from my previous experience. Helix fixes this for me.

[Biggiesized]

Thanks a million for this codec, karl_lillevold!

Xvid and FFVFW wouldn't register their .dll files correctly in the registry for YV12 playback on my Windows Vista Ultimate 64-bit SP2 setup.

Your codec installed in a hitch and works beautifully!

[karl_lillevold]

Minor update: 1.3 (11/03/10): Increased max. supported resolution from 2048 x 1152 to 8192 x 8192.
There's no need to upgrade for most users. I needed it for 3D HD videos, which are frequently represented as standard HD resolution videos, where the two views are combined side-by-side or top-bottom.

Download: Helix YUV Codecs v1.3 (http://www.lillevold.com/files/yuvcodecs-1.3.exe)

[b66pak]

thanks a lot...
_

[protovision]

link to Helix YUV 1.3 is down, any mirrors?

[karl_lillevold]

The link is working for me at the moment, but it's not a good idea to host anything useful on a server on Comcast's network. I'll put it somewhere else asap. What is a minimally annoying file sharing service ;) ?

[protovision]

yep, original link is now working thx!

as for a host recommendation, I've d/l from MediaFire, pretty good. As long as its one small archive, I think any of the free services will do. It's when its a large, multipart archive, then those free hosts turn into a pain :)

[Midzuki]

Download:

Helix YUV Codecs v1.3 (http://www.lillevold.com/files/yuvcodecs-1.3.exe)

www.lillevold.com is down (again) :—/

[karl_lillevold]

Thanks for letting me know. I figured out the problem this time. My Dynamic DNS service keeps messing up. That should be fixed in a few hours, but I have placed it on a public fileserver as well (http://www.mediafire.com/?cgux4cdtouy5v57).

I have rarely seen a more annoying page :( Without AdBlock, it's chock full of ads and pop-ups pretending to be download links. Argh. It will have to do for now. With AdBlock, it's not too bad though.