Mayday ! AviSynth is making VDubMod crash !

[KR]

Hello everyone !
I'm having some trouble with either AviSynth or the plugins I use, and I'm totally clueless about how to isolate the problem.

Having loaded my avs in Vdubmod for some additionnal processing and encoding, it would keep crashing, and I'd sometimes get what seemed like memory leaks.
The memory leaks are gone now that I replaced fft3dgpu by fft3dfilter, but it's sad because it is now about 3 times slower.

Having noticed that VDubmod would keep crashing at the exact same frame of my first clip, I tried with the other clips and after more than 3 days of the computer doing non-stop post-processing, haven't had a single problem.

Now I'm left with my first clip. VDubMod crashes at frame #737. Always.

I updated MVTools to 2.0.9.1, and modified my script to the new syntax. Still crashing.

I opened the avs in Media Player Classic Homecinema to see if it would crash also.
No crash, but after a certain frame it jumps a few frames and I get a black screen with a red message (I think it's an AviSynth message, which is why I post in this forum).
The message is:
CAVIStreamSynth: System exception - Access violation at 0x0, reading from 0x0.

BTW, the file which is loaded by my avs script (1440x1080 Huffyuv, in YUV format, with 48 kHz stereo PCM uncompressed) is not corrupted, it can be read by both MPC-HC and VDubMod flawlessly.

Here's my avs script:

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mvtools.dll")
Import("C:\Program Files\AviSynth 2.5\Scripts\2dcleaner.avsi")
Import("C:\Program Files\AviSynth 2.5\Scripts\limited sharpen.avsi")

AVISource("input1.avi").AssumeFrameBased
filtered = ConverttoRGB32(matrix="Rec709").VD_2DCleaneroptp3(8, 5, 5).ConvertBacktoYUY2(matrix="Rec709")

super = MVSuper(hpad=16, vpad=16, pel=2, chroma=true, sharp=1, rfilter=1)
superfiltered = MVSuper(filtered, hpad=16, vpad=16, pel=2, chroma=true, sharp=1, rfilter=1)

backward_vec1 = MVAnalyse(superfiltered, blksize=8, search=3, searchparam=8, isb = true, chroma=false, delta=1, truemotion=true, overlap=4)
forward_vec1 = MVAnalyse(superfiltered, blksize=8, search=3, searchparam=8, isb = false, chroma=false, delta=1, truemotion=true, overlap=4)

MVDeGrain1(super, backward_vec1, forward_vec1, thSAD=512, thSADC=512, plane=4, limit=255, thSCD1=512, thSCD2=128)

LimitedSharpen(ss_x=1, ss_y=1, Smode=3, strength=100, Lmode=1, wide=false, overshoot=0, soft=1, edgemode=0, special=true)
ConverttoRGB32(matrix="Rec709")



I'm 100% certain that 2dcleaner is not the problem. It wasn't in my script in the beginning and VDubMod still crashed at frame #737.
Also, at some point I replaced MVDegrain1 by a few MVCompensates, interleave, temporal denoiser, select every 3,1 and still it crashed at frame #737.

Any advice/tip will be appreciated.

Thank you very much !

[kemuri-_9]

check the memory/page file allocation to the program you're opening with avisynth. (use taskmgr, procexp, or something similar)

If it did hit 2 GB, then that would be your problem and you would need to set the SetMemoryMax(val) option
within it something that would wall avisynth and the accompanying program from hitting the 2GB limit

something like 1536 or 1280 (1.5 and 1.25 GB respectively) should be a good enough limit for avisynth directly,
to allow the accompanying program some breathing room.

However this is only a solution if that indeed is the problem.

[KR]

Thank you for your answer,

I monitored the memory usage of VDubMod+AviSynth during the processing:

Upon starting, Memory usage rapidly went to approx 399 000 K and remained relatively constant. (delta~0). Peak Memory Usage was 399 556 K. VM Size was 424 004K, also relatively constant.
Parameters stayed the same for the first 735 or 736 frames, without crashing.

On frame 736 or 737, Mem Delta changed to more than 2 megs, and Peak mem usage instantenously went to 424 136 K. (about 24 megs higher) The crash happened.

Still 424 136 K + 424 004 K = 848 134 K, which is < 2 097 152 K, therefore I think the 2 GB limit would not be in cause.
But there was a sudden change in memory usage.


Also, I trimmed my input video (deleted the 735 (0 to 734) first frames, and kept only the 5 following frames). Saved this 5 frame video into a new file.
Processing it with my avs file crashes at frame #2, which was originally frame #737.
I guess I could circumvent the problem by just removing that frame, processing the video, and reinsterting it afterwards, either untouched or retouched in a photo program, lol, but I'd still like to understand the problem.
Some MVTools bug ?

[KR]

New info:

Nope it's not MVTools.

Even with this 1-line script:
AVISource("input1trimmed.avi")

the crash still happens...
again only on this specific frame.


I had derived my trimmed input video from the original by using direct stream copy.
I tried again using fast recompress instead, just in case there would have been an error in the original stream. Again, same crash.

In order to open that specific frame with AviSynth, it needs to have been ever so slightly altered, such as having been previously converted to RGB and back to YUV2. Then AviSynth doesn't crash.

So AviSynth 2.5.7 probably has a bug.

[kemuri-_9]

have you tried it with avs 2.5.8 RC?
odd that it only happens on one frame...
what video codec is the file you're opening and what are you decoding it with into avs?

[Fizick]

KR,
if you have small part of trouble AVI, upload it to some server like rapidshare, etc...

[talen9]

If you recently installed RemoveGrain dlls, mind that some versions of it have the RemoveGrainSSE3.dll defective, meaning that only having it into AviSynth's default plugin folder leads to the crash you're seeing ... you'd best removing it and replacing it with SSE2 version (speed is more or less the same).

[IanB]

This sounds like the bug with the video codec pre-reading beyond the end of the input buffer when decoding some video frames. Huffyuv and XviD are both known to do this, other codecs have been reported as well.

2.5.8 provides a workaround by adding guard bytes to the end of all input buffers allocated. It also fixes the problem of always mis-reporting "... at 0x0, reading from 0x0" introduced in 2.5.6 (and 2.5.7)

[KR]

I do have RemoveGrainSSE3.dll. Had to install it for use by LimitedSharpen. I got it from http://home.arcor.de/kassandro/RemoveGrain/RemoveGrain.rar
Version 1.0 . Is it the defective one ?

The reading beyond input buffer makes sense, I'm just surprised it happened on one frame only.
First time I've seen this happen...
I used Huffyuv 2.1.1 for encoding, and decoding also. Huffyuv decoding by ffdshow is currently disabled. Does the ffdshow VFW huffy decoder has the bug ? I'll try it after work today.

If it doesn't work I'll try AviSynth 2.5.8.

Here is the trimmed avi:
http://mydriaz.com/download/input1trimmed.avi

Thanks to everyone !

[talen9]

I do have RemoveGrainSSE3.dll. Had to install it for use by LimitedSharpen. I got it from http://home.arcor.de/kassandro/RemoveGrain/RemoveGrain.rar
Version 1.0 . Is it the defective one ?


I actually don't remember if that's the one ... but you could simply try moving the SSE3 dll out of the plugins folder and see if the script starts working, can't you? :)

After reading again your original post, I tend to agree with others about high memory consumption and the need to raise the value of SetMemoryMax ... RemoveGrainSSE3.dll can be at least partly responsible, though.

[KR]

Moving out RemoveGrainSSE3 doesn't prevent the crash.

Using ffdshow as Huffy decoder doesn't either.

Using Avisynth 2.5.8 did solve the problem.

Thanks again

[IanB]

If you stop and think for a minute, you will realise the RemoveGrainSSE3.dll. problem does not fit the profile. It crashes as soon as you access it. This problem crashes on access to a certain video frame.

To witness the Huffyuv bug the maximum compressed frame size must be an exact multiple of the windows page size. The frame in question must be that maximum size. And the last code in the compressed frame must be between 9 and 23 bits long. The ffdshow huffy code is related to the original Huffyuv code by BenRG, so probably has the problem.

[thetoof]

Sneaking in for a suggestion: have you tried using Lagarith?

[squid_80]

To witness the Huffyuv bug the maximum compressed frame size must be an exact multiple of the windows page size. The frame in question must be that maximum size. And the last code in the compressed frame must be between 9 and 23 bits long. The ffdshow huffy code is related to the original Huffyuv code by BenRG, so probably has the problem.
I honestly thought nobody would ever trip this bug again :eek:
Very surprising that it's been hit twice reasonably lately, given people have been using huffyuv and avisynth together for ages.

I thought the huffyuv codec in ffdshow (libavcodec) was completely rewritten, unusual that it still crashed.

[talen9]

If you stop and think for a minute, you will realise the RemoveGrainSSE3.dll. problem does not fit the profile. It crashes as soon as you access it. This problem crashes on access to a certain video frame.

I realized that after reading better the original post; first time I read it and posted, I thought the error came right from the start.