Insert thread-blocking pause in script after FFIndex?

[miamicanes]

I'm having a problem with VirtualDub crashing every other time I load a video, and crashing after each (occasionally, every other) video in a batch job. I'm 99% sure at this point that it has something to do with VirtualDub/Avisynth triggering FFIndex, then allowing one or more other threads to proceed with the script before it finishes.

Clues:

When I load a script into AvsP, the UI hangs for 5-60 seconds (depending on whether I have VirtualDub and/or TMPGenc rendering other stuff in the background), then I get an error that usually complains that the source video has no audio. If I hit f5 again (or just navigate to the next frame), the error goes away, and it works fine until I change the source or load a new script.

Likewise, when I load the script into VirtualDub, it usually gives the same error immediately (unlike AvsP, it doesn't hang the UI), but if I wait a few seconds, then navigate to the next frame (or just wait a few more seconds), the error goes away, and it works fine for the remainder of the session.

My guess: VirtualDub is loading the script, launching into it, triggering FFIndex... then it (or avisynth) is allowing one or more threads to barge on ahead before it finishes. One of those threads crashes, causes Avisynth to end, and VirtualDub freaks out.

So... at the kludge end of the spectrum... is there an Avisynth command/filter that basically says, "wrap this function/filter, execute its body before doing anything else, and block all other threads until it completely finishes"? And/or maybe a virtualdub setting that means, "If you get an error while rendering an item in a batch job, before crashing or giving up, wait 60 seconds, then try executing it again to see whether it works the second time around."?

Versions I'm currently using:

VirtualDub 1.9.10, compiled with VS2005 for X86. Build 32839/release (Sunday, September 5, 2010)

Avisynth.dll:

file=2.5.8.5, productversion=2.5.8.0, date 12/21/2008 (in c:\windows\SysWOW64)

I have another copy of avisynth.dll sitting in the avisynth plugins directory that's 2.5.7.0 from 3/1/2007.

I have a third copy (2.5.7.0, seems to be the same as the one in the plugins directory) in c:\Program Files (x86)\Avisynth

AddGrainC.dll: 1.5.0.0 (don't think this is the culprit, it was crashing long before I started using it)

ffms2.dll: 'details' tab is devoid of info besides sides (2.23mb) and date modified (8/26/2009, 6:45pm)

ffmsindex.exe: 9.00kb, 8/26/2009, 6:45pm

mvtools2.dll: 2.5.11.0, v2.5; 616kb, 10/18/2010, 2:06am


If Avisynth and/or VirtualDub has a logfile somewhere, I haven't found it/them yet.

Update: I found the log for VirtualDub. Here's what it said when it crashed a couple of minutes ago (after finishing one, then crashing at the end of the second):

Problem signature:
Problem Event Name: BEX
Application Name: VirtualDub.exe
Application Version: 1.9.9.0
Application Timestamp: 4c84657d
Fault Module Name: AviSynth.dll_unloaded
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 494eb94d
Exception Offset: 100e05ef
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
Additional Information 1: 0f31
Additional Information 2: 0f3137665bbf0bb676c8a16f3fa76e52
Additional Information 3: 1ecf
Additional Information 4: 1ecf7c919bd68f02115a00deef8ba3bb

[Gavino]

:script: - both AVS script and batch script.

Are you perhaps using the same index file for different runs simultaneously?

FFIndex() does its work at 'compile-time' (script parsing and filter graph construction) and the next line of the script will not be compiled until it is finished. I would expect any multi-threading to happen only at 'run-time' (ie during frame-serving).

[miamicanes]

The .avs file (generated with Avisynth Batch Scripter)

Clip="ab-179j"

FFIndex("K:\720p239\" + Clip + ".mp4")
FFmpegSource2("K:\720p239\" + Clip+".mp4", vtrack=-1, atrack=-1)

BilinearResize(640,360)

super = MSuper(pel=2)
backward_vec=MAnalyse(super, overlap=4, isb=true, delta=1, search=3)
forward_vec=MAnalyse(super, overlap=4,isb=false, delta=1, search=3)
Q = MFlowInter(super, backward_vec, forward_vec, time=200.0/3).SelectEven() #200.0/3
A = SelectEven()
B = SelectOdd()
Interleave(A, A, Q, B, B)

AddGrain(4,.1)


For the script, I'm just using VirtualDub's "batch wizard" to select the .avs files, rename the output to .avi, and queue them.

I've noticed that I can always get the first in the queue to render, but it dies unless I've personally loaded the next in line into VirtualDub and played a few frames of it before launching the batch job. I've replicated this for one, two, and three files (ie, if I individually load and play a few frames of the first three in the list, it'll die on #4).

[Gavino]

It sounds like some sort of timing problem with one or more components of ffms2.

Does it make any difference if you remove the call to FFIndex()?
It's actually redundant since, with the parameters you are using, FFmpegSource2 will call it again anyway.

[miamicanes]

Hmm. I don't know. I'll try it now.

[miamicanes]

Update: VirtualDub is no longer crashing every few times. Whether it's because I removed the FFindex, or because I uninstalled and reinstalled Avisynth, I can't say for sure.

I suspect use (or non-use) of VirtualDub's batch wizard might be a factor, too. I quit using the wizard yesterday, and just went back to loading the .avs files one by one into VirtualDub and adding the "save to avi" jobs to the queue. So far, it's finished about a dozen videos, and still going strong.

Now, I just need to figure out how to get DirectShowSource to work so I won't have to keep converting .wmv files to .avi/huffy using XmediaRecode first as a separate step (FFmpegsource2 doesn't support the wmv files' audio codec; apparently, that's intentional and by design).

[Gavino]

Now, I just need to figure out how to get DirectShowSource to work so I won't have to keep converting .wmv files to .avi/huffy using XmediaRecode first as a separate step (FFmpegsource2 doesn't support the wmv files' audio codec; apparently, that's intentional and by design).
How about using DirectShowSource for the audio and FFVideoSource for the video?