Uncompressed UYVY AVI fails to load in AviSynth (plays fine in VirtualDub 1.8.5)

[chaynik]

For the longest time I've been looking for the most efficient and lossless way to exchange uncompressed YCbCr 4:2:2 video between Windows and Mac platforms. The closest I've come was using the QTSource plugin in AviSynth to load Uncompressed 4:2:2 MOV files into AviSynth and go from there. However, I've noticed that this approach is not frame accurate, seeking to a specific frame in the AVS script does not match the same frame number in QuickTime Player on Mac. Further, these differences are not constant, and vary throughout the file. I've noticed as much as 15 frames difference seeking throughout the same file. Such behavior makes me a bit scared of using QTSource, as much as I appreciate the developer making such a tool.

Recently I've discovered that the tool MPEGStreamclip for Mac has the option to export an AVI using any of QuickTime's codecs, Uncompressed 4:2:2 included. The exported AVI reports the FourCC as "2vuy" on Windows, which is exactly the same as the UYVY FourCC. By modifying the FourCC in the AVI, I am able playback the file in VirtualDub 1.8.5. There still seems to be a 1 frame difference when seeking to specific frame numbers, but 1 frame I can live with :)

Now, having said all that, I am unable to get this file to load into AviSynth, with FourCCs forced or otherwise. Naturally, I am using "AVISource" as the input. AviSynth reports "Could not decompress frame 0." I've tried using the Trim function thinking the first frame may be corrupt, but to no avail. The fact that VirtualDub is able to open and playback the file gives me hope, but in the end I would really like AviSynth to be able to do so as well. I've tried different versions of AviSynth, including the latest 2.58 build.

Any suggestions would be greatly appreciated. Also, if anyone has approached this workflow using a different method and/or using a different combinations of tools, I'd love to know more about it.

Thank you very much in advance!

[Placio74]

For this, VirtualDub have internal decoder.

For AVISource need installed required codecs.

For UYVY example The Drastic YCbCr Codec (http://www.drastictech.com/download_codec.html).

This Y'CrCb codec includes support for a wide variety of four'cc compression codes including:
I420, IYUV, YV12 - 4:2:0 8 Bit Planar
UYVY, YUY2, 2vuy, 2Vuy, yuv2 - 8 Bit Interleaved 4:2:2
YVYU, YUYV, YUNV, UYNV, cyuv - 8 Bit Interleaved 4:2:2
V422, P422 - 4:2:2 8 Bit Planar
v210, 012v - 4:2:2 10 Bit Interleaved
auv2 - 4:2:2:4 8 Bit Interleaved
a12v - 4:2:2:4 10 Bit Interleaved

Or...

Unfortunately Avisynth's AVISource() does not support "UYVY" format for direct input like VDub does, "YUY2" is currently the only supported packed 4:2:2 format for direct input.

So you will need a UYVY codec.

On my PC's the ubiquitous msyuv.dll, which seems to get installed with all and sundry things video, fits the bill (over 20 .inf files reference it).

You are probably already have the codec but it is not registered for VFW use.

Check to see if you have msyuv.dll in your Windows system32 directory.

If so add these keys to your registry.[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Drivers32]
"VIDC.UYVY"="msyuv.dll"
"VIDC.YUY2"="msyuv.dll"
"VIDC.YVYU"="msyuv.dll"If not then a little google-foo will point you to a copy of it.

Failing all this you could try DirectShowSource() but that almost certainly will convert to RGB format.


BTW
If installed Helix codec (and maybe Xvid, i'm not sure), it try decode UYVY instead other codecs (exclude Drastic - msyuv i'm not check, but maybe) and then have "cannot decompress frame 0".

[IanB]

AviSource() only supports Uncompressed 4:2:2 as YUY2.

You can try RawSource() or installing a UYVY codec, like msyuv.dll or blackmagic.

Virtualdub can quickly transcode the files from UYVY to YUY2.

These 2 threads recently discussed the issue. ""couldn't locate decompressor" yet no fourcc given" and "Unable to load UYVY"


This script will force a file to be read as if it were YUY2, but of course the pixel byte order will still be wrong, so you need something to rearrange the bytes...AviSource("uyvy.avi", false, "YUY2" , "YUY2")

U=PointResize(Width()/2, Height)
V=PointResize(Width()/2, Height, 1)
Y=Interleave(UtoY(), VtoY()).TurnLeft().AssumeFieldBased().Weave().TurnRight()

YtoUV(U, V, Y)This is quite slow, a little google-fu may find a filter you can abuse to just swap the bytes within words quickly.

@Placio74, Snap :D

[chaynik]

Thank you all for the replies. I have tried some of the mentioned approaches even before posting my thread, I should have mentioned that originally. Repacking the AVI in Vdub using 'Fast Recompress' yielded a "green AVI." I'm not talking video with a green tint (which would signify data being read out of order), but literally 4 minutes of a static green image. Confirmed in virtualdub, (where file info still reports it as UYVY despite the assumption that it should be repacked to YUY2). Media Player and Avisynth both display this AVI the same way.

I already had an entry in my registry for UYVY, and it did in fact point to 'msyuv.dll" I tried changing it to huffy.dll per some other thread in this forum, but that yielded no results as well. I do have the Helix codec installed, but I'm assuming it's not working either since I'm still unable to play back the AVI.

I have not tried the Drastic or Blackmagic codecs, will test and report back.

Will also try the script IanB suggested.

As far as RawSource, I have experimented with it and the original quicktime file, since ideally I would like to not have to make an AVI intermediate on the Mac, that would save some time and space. I also have no idea what exactly MPEGStreamclip does to the video when saving as AVI (I would hope it simply adds an AVI header and passes through the data). Still, it was the only Mac tool I was able to find that could save an AVI to anything other than "None" (aka RGB) or DV (the only options QuickTime has when exporting as AVI). I was able to decode half of the quicktime file using RawSource and yuvscan.exe to calculate the offsets, but just past half of file (about 2 minutes in) the picture started "rolling". Not sure exactly what happened, perhaps someone may know?

I am surprised that no tool exists to simply "repack" 4:2:2 AVIs to MOVs and vice versa. I would imagine it would be quite simple since it's all raw YCbCr data. Well, I can dream :)

Also a bit offtopic, but something that I've been wondering... I experimented withh HuffYUV prior to uncompressed 4:2:2 since the QuickTime component known as 'Perian" has HuffYUV support. I noticed in virtualdub when selecting the codec under compression, HuffYUV lists valid depths as '24' only... Why is that? That and Perian's unfortunate broken HuffYUV support (it seems that it incorrectly and pointlessly converts HuffYUV video to RGB, because exporting a HuffYUV file to Uncompressed 4:2:2 in QuickTime causes color shifts) turned me away from HuffYUV, as much as I would have loved to take advantage of its smaller file sizes.

Thanks again to all for the help!

[Wilbert]

You can try RawSource()
Can you abuse RawSource to load uncompressed AVI?

I guess it shouldn't be difficult to add it to RawSource or ImmaRead. But, sorry, i've other things to do :)

@chaynik,
Could you upload a >5 frames sample somewhere?

[chaynik]

Here are some samples: http://rapidshare.com/files/142366843/chaynik_uyvy_samples.rar.html

Identical video but exported with 3 different QuickTime "codecs." "Blackmagic 8 Bit (2Vuy)," "Apple FCP Uncompressed 8-bit 4:2:2," "Apple Component Video - YUV422." I suspect they're all identical but thought I'd include all 3 anyway. 96 frames @ 23.976 fps. ~52MB RAR archive.

Thanks!

[IanB]

Repacking the AVI in Vdub using 'Fast Recompress' yielded a "green AVI."This is quirk. You must choose Video -> "Full Processing mode" and select "4:2:2 YCbCr (YUY2)" for the "Output format to compress/display" under Video -> "Color Depth ..." and select "(Uncompressed RGB/YCbCr)" under Video -> "Compression..."

However if you are going to transcode, you might as well save some disk space and use HuffYUV compression. You can use "Fast Recompress" mode for this.

[chaynik]

This is quirk. You must choose Video -> "Full Processing mode" and select "4:2:2 YCbCr (YUY2)" for the "Output format to compress/display" under Video -> "Color Depth ..." and select "(Uncompressed RGB/YCbCr)" under Video -> "Compression..."

However if you are going to transcode, you might as well save some disk space and use HuffYUV compression. You can use "Fast Recompress" mode for this.
So is the correct behavior of fast recompress to repack to YUY2 and it's not working in my case?

I would love to use HuffYUV but that "valid depths: 24" display kind of scares me... I keep on thinking horrible thoughts of video being converted to RGB prior to being passed to huff and then converted back to YCbCr. Am I being just paranoid?

[IanB]

@chaynik,

No "Fast Recompress" mode just directly connects the input stream to the output stream with no intervening processing. There is some negotiation so you cannot feed YUV data into a codec that only accepts RGB data. For direct file output UYVY and YUY2 are treated interchangably, this is probably a bug. The result should be the same as force opening the original file with AviSource("uyvy.avi", false, "YUY2" , "YUY2"), i.e. there is no data bytes reordering, so it looks all green.

In this case we need to make VirtualDub add a UYVY to YUY2 byte swap converter to the graph. The converter is only available in"Full Processing mode", hence the quirk. If you lock the input and output formats to be what you want there can be no mistakes. Check the log window to see what was negotiated.

You can use my slow byte shuffling script with the original file to compare any of your processing paths to ensure accuracy.



As for using HuffYUV, paranoid, slightly maybe. More likely you are just being warey of something that is poorly documented. When using direct file input with "Fast Recompress" mode there are no converters available so the negotiation is :- I support UYVY mode only, is this acceptable? HuffYUV does correctly support this on input. so you get exactly what you need.

If you open the configuration dialog for HuffYUV there are 2 lists of compression options. The right list is to do with RGB input data and includes an option to convert to YUY2. The Left list is to do with UYVY/YUY2 input data. Do not choose the best YUY2 compression mode for generic workfiles it is very much slower to decompress than the lesser modes for only a marginal gain in compression.

If you input RGB data HuffYUV works according to the right hand list, if you choose to convert to YUY2 then is internally does a RGB->YUY2 conversion and proceeds as for YUY2 input.

If you input UYVY/YUY2 data HuffYUV works in YUY2 mode according to the left hand list. There is no option to convert YUY2 to RGB on input.

[chaynik]

Great news! I was able to use RawSource to correctly load my Uncompressed 4:2:2 MOVs into AviSynth with no rolling or "green." The trick was to use "index="0:512" in the RawSource line. Like so:

RawSource("movie.mov",720,480,"UYVY", index="0:512")

I just experimented with random index numbers until I stumbled upon one which worked. I hope this approach is okay, since with uncompressed video things are generally simple. Or am I wrong?

On the flipside of things, outputting a UYVY AVI out of VirtualDub is perfect! In fact, I can even edit these AVIs directly in Final Cut without any rendering (Final Cut has only a limited selection of "realtime" codecs, namely DV, Uncompressed 4:2:2 and ProRes422), something that was not possible with YUY2 AVIs (even though they were playable).

The last thing I want to touch on is 4:2:0-->4:2:2 upconversion. I deal with a number of files that are 4:2:0 and must upconvert them to 4:2:2 to work with them on the Mac (afaik, QuickTime does not support any 4:2:0 FourCC's besides y420, which does not have a Windows counterpart). Now, are there any differences between AviSynth, VirtualDub and HuffYUV 420--422 upconverters? That is, should I add a "ConvertToYUY2" line to my AVS script prior to feeding this file into VirtualDub for UYVY output or can VirtualDub handle the conversion just as well? Also, does HuffYUV perform this upconversion itself when fed YV12 video and how well does it do it?

Thanks to everyone for your tremendous help!

[hanfrunz]

Why don't you use tateu's qtinput()-plugin (http://forum.doom9.org/showthread.php?t=104293)?

It can import raw data in these formats: uyvy (2vuy), yuyv (yuy2), yvyu, vyuy, yuv2, rgb, argb

hanfrunz

[LigH]

Long ago, still an issue: The msyuv.dll seems to support only conversions to RGB. AviSource("UYVY.avi", pixel_type="YUY2") fails in Windows 7. AviSource("UYVY.avi") returns RGB32.

If you have ffdshow installed, it is able to convert UYVY to the next similar format if desired (in fact, YUY2 is just a "Little Endian / Big Endian" swap of UYVY). You just have to register the VfW codec of ffdshow (ff_vfw.dll) to handle these formats. Note: Without pixel_format parameter, ffvfw prefers YV12 output.

WARNING! Samples provided without warranty, first back up the registry branch to be patched! Installation of ffdshow (32 bit) and enabling the decoding of raw formats in its "VFW Codec Configuration" is required!

Save the code matching your Windows version (32 or 64 bit) to a *.reg file (preferably in Unicode format) and import it to your registry.

yuv_vfw_win32.reg
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
"vidc.uyvy"="ff_vfw.dll"
"vidc.yuy2"="ff_vfw.dll"
"vidc.yvyu"="ff_vfw.dll"
"vidc.iyuv"="ff_vfw.dll"
"vidc.i420"="ff_vfw.dll"
"vidc.yvu9"="ff_vfw.dll"

yuv_vfw_win64.reg
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32]
"vidc.uyvy"="ff_vfw.dll"
"vidc.yuy2"="ff_vfw.dll"
"vidc.yvyu"="ff_vfw.dll"
"vidc.iyuv"="ff_vfw.dll"
"vidc.i420"="ff_vfw.dll"
"vidc.yvu9"="ff_vfw.dll"

I guess ffdshow should have been able to do so during its installation. But it seems to fail to re-register these formats while changing decoding support of raw video formats after it has been installed.