Avisynth handling of dropped frames

[iparout]

Hi.

I captured a raw YUY2 clip from my VHS and when I open it through avisynth in VirtualdubMod, I get 1-2 green frame every 8-9 normal frames.

I noticed that those green frames aren't there when I load the raw avi into VDubMod.

The avisynth script I used is only :

Avisource("d:\capture.avi")

When I compressed the raw avi to huffyuv, and then loaded it in VDubMod through avisynth again, the problem wasn't there, so I guess it has to be a bug (?) in Avisynth when using raw video...

Does anyone know what might be causing the problem ?

I am using Avisynth 2.54 and VDubMod 1.5.10.2 BTW.

Thanks in advance.

[AI]

Green frames, then U=V=0

(in black (grey) frames, normal U=V=128)

[Mug Funky]

not necessarily a bug in avisynth - virtualdub requests RGB video by default, whereas avisynth requests YV12 by default, falling back on yuy2 and finally rgb.

if your default yuy2 codec is a little strange (msyuv.dll?) then it might not behave correctly at returning yuy2, but works fine for rgb24.

so what you could try is installing ffdshow (find the latest with search :)) and setting it to decode all types of uncompressed. access it through start > programs > ffdshow > vfw config.

[Wilbert]

1) Check your vidc.yuy2 setting in your registry, and let it be decoded by huffyuv.dll. (YV12 faq explains how to do it for YV12.)

2) Use RawSource.

[iparout]

1) Check your vidc.yuy2 setting in your registry, and let it be decoded by huffyuv.dll. (YV12 faq explains how to do it for YV12.)

I did what you suggested, however I don't have the raw video anymore to test if it worked. Next time I have a raw video in my hands, I'll see what happens and if the problem persists, I'll post here again.

Thanks in advance everyone.

[iparout]

Unfortunately, it didn't work. Still green frames... :(

[Fizick]

Avisynth 2.54 ?
Why not 2.5.6 ?

try converttoYUY2()

[iparout]

Ok, I figured that the frames that appear green are the dropped frames of the video. When I open the original RAW video file in VDubMod, a [D] appears for each of those frames, however, when I open the file through avisynth, green frames appear where the dropped frames where...

So I was wondering, how is it possible to prevent this ? (Not prevent dropped frames, just to prevent them from turning up green i.e. delete them or replace them with the previous frame).

P.S. : When capturing, I enabled the "resample audio data dynamically" option.

P.S. 2 : I changed the title so that it corresponds more accurately to the problem.

[Boulder]

That's weird behaviour. VDub should simply copy the last captured frame when a drop occurs and not cause any green frames.

Could you upload a clip of a couple of frames where the green frame issue occurs, preferably with a few frames before and after the drop point.

[iparout]

Ok, here's the clip of the raw video. It's rar'ed to save space.

WARNING : Rar file is 20MB.

http://rapidshare.de/files/6459310/sample-raw.rar.html

The dropped frames are 37, 54 and 61.

Just create a simple avs file like Avisource("c:\sample-raw.avi") and open the avs through VDubMod. The dropped frames appear as green...

[Boulder]

Weird behaviour :eek:

However, if you convert the colorspace, the problem is gone. If you convert back to YUY2, there's no green frames. There must be something in the way Avisynth handles a raw YUY2 stream without any processing.

Still, you're much much better off using HuffYUV when capturing.

[iparout]

I see. Can you please tell me exactly how the following script should be modified in order for the problem not to occur and also to prevent any problems from converting the colorspace and using the following filters ?

# PLUGINS
LoadPlugin("c:\PixieDust\LoadPluginEx.dll")
LoadPlugin("E:\GORDIA~1\Msharpen.dll")
LoadPlugin("c:\PixieDust\dustv5.dll")
LoadPlugin("E:\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("E:\GORDIA~1\undot.dll")
LoadPlugin("E:\GORDIA~1\decomb.dll")
LoadPlugin("E:\GORDIA~1\KernelDeInt.dll")
#LoadPlugin("E:\GORDIA~1\dgbob.dll")
#LoadPlugin("E:\GORDIA~1\Convolution3d.dll")
#LoadPlugin("E:\GORDIA~1\FluxSmooth.dll")
#LoadPlugin("E:\GORDIA~1\TomsMoComp.dll")
#LoadPlugin("E:\GORDIA~1\VSFilter.dll")
#LoadPlugin("E:\GORDIA~1\SimpleResize.dll")

Avisource("f:\capture.avi")

# DEINTERLACING (2)
KernelDeint(order=1)

#CROPPING
Crop(18,12,-14,-12)

#DENOISE
PixieDust(5)

#SHARPEN
MSharpen()

#RESIZING
LanczosResize(640,480)

I know that I should capture to huffy, however I experience more dropped frames when capturing to huffy, that's why I prefer to handle raw data, since I don't have a problem with diskspace.

[Boulder]

# PLUGINS
LoadPlugin("c:\PixieDust\LoadPluginEx.dll")
LoadPlugin("E:\GORDIA~1\Msharpen.dll")
LoadPlugin("c:\PixieDust\dustv5.dll")
LoadPlugin("E:\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("E:\GORDIA~1\undot.dll")
LoadPlugin("E:\GORDIA~1\decomb.dll")
LoadPlugin("E:\GORDIA~1\KernelDeInt.dll")
#LoadPlugin("E:\GORDIA~1\dgbob.dll")
#LoadPlugin("E:\GORDIA~1\Convolution3d.dll")
#LoadPlugin("E:\GORDIA~1\FluxSmooth.dll")
#LoadPlugin("E:\GORDIA~1\TomsMoComp.dll")
#LoadPlugin("E:\GORDIA~1\VSFilter.dll")
#LoadPlugin("E:\GORDIA~1\SimpleResize.dll")

Avisource("f:\capture.avi")
ConverttoYV12(interlaced=true)

# DEINTERLACING (2)
KernelDeint(order=1)

#CROPPING
Crop(18,12,-14,-12)

#DENOISE
ConverttoYUY2() # or preferably use some other denoiser than PixieDust and stay in YV12 throughout the process!
PixieDust(5)

#SHARPEN
MSharpen()

#RESIZING
LanczosResize(640,480)
I suggest you use some other denoiser than PixieDust to avoid another YV12->YUY2 conversion. Your final codec probably uses YV12 so the whole process will be YUY2->YV12->YUY2->YV12 which will result in lower quality. If you don't use PixieDust, it'll be YUY2->YV12 only, and this would happen in any case.

Take a look at LRemoveDust, the function can be found at the RemoveGrain thread. It's similar to the Dust filters but a whole lot faster.

[iparout]

Aha, I see. However I noticed that, IMHO, PixieDust smooths and cleans the picture better than LRemoveDust(17,2) and makes it around 17% more compressible (using Xvid). But it takes x3 the time !!!

I'll make a few tests and see how it goes.

But it's good to know that my problem is a bug in avisynth and that I didn't screw up during the process.

Thanks.

[Boulder]

Aha, I see. However I noticed that, IMHO, PixieDust smooths and cleans the picture better than LRemoveDust(17,2) and makes it around 17% more compressible (using Xvid). But it takes x3 the time !!!

Try LRemoveDust(17,5), it'll limit the change to 5 pixels like PixieDust(5), or combine LRemoveDust(17,2) with TemporalSoften(2,3,3,8,2) or something like that.

[scharfis_brain]

boulder: forcing YV12 is a bad idea.
try rgb24 or rgb32 before unecessary reducing chroma resolution.

[Boulder]

As he seems to use AutoGK/Gordian Knot (looking at the script), I assumed he's going for MPEG4 so he'll end up with YV12 anyway.

EDIT: or do you mean he should convert to RGB24 first and then to YV12 after resizing?

[scharfis_brain]

you may convert to yv12 after deinterlacing, but never ever do it before.

[iparout]

I tried to use higher strenght in LRemoveDust, however the result is still not what I want it to be. I am much more satissfied with PixieDust(5).

Also, if I use ConverttoYV12 immediately after avisource, the green frames vanish, however there are some "hickups" (frames going back and forth), where the green frames used to be (and I am using the correct field order in KernelDeint).

And to make matters worse, if I use converttoYV12 after delace, as scharfis mentions, some of the green frames vanish, and others are still there (i.e. frame 54 in the clip I posted above).

I'm totally confused now... Maybe I'll just continue doing what I've been doing up to now. Capture in raw YuY2 format and then encode to huffyuv before postprocessing.

[foxyshadis]

I wonder if converttoyv12 is sometimes cloning a field from the last frame (thus causing a motion reversal on that field) rather than the opposite field of the same frame, which would be the most logical. You might have to make a short function to actually look for U/V=0 and clone the other field. Messy.

[Mug Funky]

hang on... kerneldeint can handle yuy2 input, and it's captured in yuy2.

so why not just leave it in yuy2 all the way through the script, then convert to yv12 at the end for xvid (or even let xvid do the conversion from yuy2 to yv12).

[IanB]

AviSource() apparently doesn't detect and handle drop frames when doing direct I/O (YUY2, YV12, RGB24 & RGB32)

I will have a look at the code.

IanB

[Boulder]

hang on... kerneldeint can handle yuy2 input, and it's captured in yuy2.

so why not just leave it in yuy2 all the way through the script, then convert to yv12 at the end for xvid (or even let xvid do the conversion from yuy2 to yv12).
KernelDeint probably sees the green frame instead of the real one?

[ChiDragon]

I've got this problem too. Sometimes it also outputs seemingly random frames from earlier in the video rather than the totally green frame, even in the same instance of VirtualDub. I can seek through the file and see green frames in the dropped spots, then go back and seek through it again and all of a sudden it's random frames instead of green. Converting color spaces doesn't make a difference for me, either.

[Wilbert]

I think IanB fixed it in coming v2.57 alpha release.

[Mug Funky]

hehe... looking at it from a production point of view, it's probably better to just not allow a capture with dropped frames :)

though i suppose it would have peculiar behaviour on those 120fps divx's that are floating around.