VirtualDub 1.10.4 crashes on this AVS, 1.9.11 does not

[FredThompson]

VirtualDub 1.10.4 does not load this AviSynth script. 1.9.11 works properly. Why would this happen?

(Systems is Win 7 SP1 x64)

DirectShowSource ("Triple wall folding test tagged.avi")

# Frame Numbers

ConvertToYUY2()
vid00=last
BlankClip(vid00,width=62,height=52,color=$000000)
SeparateFields()
AssumeTFF()
SelectEven()
vid01=ShowFrameNumber(text_color=$00FF00)
Layer(ConvertToRGB32(vid00),ConvertToRGB32(Crop(vid01,0,4,-0,-0)),"add",x=567,y=448,use_chroma=true)

Avery's forum isnt' working properly just now...

[videoh]

"does not load" is pretty vague. Specifically, what error message do you receive?

[FredThompson]

Try loading the script (with a proper filename) into VirtualDub yourself.

[raffriff42]

We don't have your source file, and we aren't running your computer. So if VD threw up an error message, post the error log please. If VD crashed completely, it should generate a "crashinfo.txt" in its home folder, please post that.


BTW VD forum is back up.

[Groucho2004]

Try loading the script (with a proper filename) into VirtualDub yourself.
Works for me. Also, what raffriff said.

[Sparktank]

Not sure why you're having issues, but it loaded for me in 1.10.4 without crashes.
Tried DGdecNV and DSS. Zero crashes/errors.

Try FFMS2 or other indexer instead of DSS.

[FredThompson]

The error message is "can't load the AVS file" or words to that effect.

That IS the error message.

Multiple WIn7 SP1 x64 computers, differing source files.

When the only variable is the VirtualDub build, 1.9 works and 1.10 refuses to load the AVS script.

There is no crash or I would have reported the dump.

From here, it looked like only a VirtualDub issue. Something must have been changed in the file loading code between 1.9 and 1.10 which messes things up here.

I'll contact Avery to see if this can be resolved.

Very odd.

[Sparktank]

"words to that effect" are not helpful.
A screenshot of the error message would suffice.

"multiple computers" (regardless of OS and bit version) and "Differing source files" are pretty strong variables, too.

Do they all have the same Avisynth version installed with all the same plugins?
Do various types of containers/formats not load either? (avi,mp4,mkv/h264,vc1,mpeg2,wmv)
Have you tried an indexer instead of DSS?
Or even tried DSS2?
Are you sure the 1.10 version is the right x86/x64 version to match your Avisynth install?
Have you tried to remux the video to new container? (*.mkv)



There's plenty more variables with little to work with.
I'm going to guess even Avery's forum, you'll end up in the same dead-end with the reluctancy you have in providing information.

VirtualDub should be giving more detailed information on the error. Some form of designation. Probably the rest of the error message you left out and summed it up as "to that effect".
That "effect" is what people need to properly get an idea of what's going on (since we know nothing about the AVS version you are using and if you're using the x64 build of VD or etc etc).

So far, everyone has tried that script with VirtualDub 1.10 without errors.
So it's not, at all, how differently VD loads a script.
The process of elimination is a long one, but accurate.

[FredThompson]

Check your attitude, there, Sparky.

You made a huge number of assumptions about the conditions, my statements, my competency, and the internal structure of VirtualDub.

So far, everyone has tried that script with VirtualDub 1.10 without errors.You can't know that, you can only read the replies in this thread.

So it's not, at all, how differently VD loads a script.You came to this conclusion based on the replies in this thread. That is not proof. You'd need to examine the source code for both versions of VirtualDub


If you had paid a little attention to my user stats, you'd see I'm not new to this ballgame.

Edit: In retrospect, I should have started this reply with, "Does that seem as rude to you as it does to me?" I apologize for being overly brusque.

I went to Avery's forum first because I've never seen this type of message. Missing codecs or crashes are ont thing. This is entirely different.

[StainlessS]

Script works for me with source SD PAL UT_Video, XP32, VD v1.10.4.

[videoh]

Start with just the source filter and see what happens. If that is alright, then add stuff incrementally.

[FredThompson]

Guys, The problem is not the script, codecs or anything else that should happen AFTER the script is loaded.

I keep stating the script won't load into 1.10 and will load into 1.9 with the only variable being the VirtualDub builds.

1.10 is primarily a bug fix release. So...what do we know? We know that I'm having this script loading issue here on multiple computers. We also know this happens when the only variable is the VirtualDub build.

Ergo, the likely place for the problem is VirtualDub 1.10's file loading routines. Maybe Avery fixed something but there is an outlier issue which crept in such as a simple syntax oversight.

Attached is the error message. I've never seen this in, what, 15 years of using VirtualDub and AviSynth? Something like that.

[Groucho2004]

Guys, The problem is not the script, codecs or anything else that should happen AFTER the script is loaded.
Are you running VDub with Admin rights?

[StainlessS]

1.10 is primarily a bug fix release

VirtualDub.org home page

VirtualDub 1.10.4 is out. It has a number of bug fixes, some small additions to the external encoding and filter color support, and addresses a small compatibility issue with the Direct3D display path and Windows 8.1.

This version also finally replaces 1.9.11 as the stable version. Many regressions have been resolved due to the amount of time that the 1.10.x branch has had to cook, and I don't like the "eternal beta" model of development. I know my work on VirtualDub has been very slow, which I apologize for, but I'd like to thank everyone who tested the experimental and test releases and reported problems.

If 'stable version' means 'bugfix release'.

Groucho comment above probably on right track.

[Groucho2004]

Ergo, the likely place for the problem is VirtualDub 1.10's file loading routines.
Based on that reasoning, a script that only contains "Version()" should give the same error, right?

[Sparktank]

Check your attitude, there, Sparky.

You're too much. Good luck.

[foxyshadis]

Attach process monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) with Process Name = virtualdub.exe, you'll get a better reason why it can't load. It's a good idea to start the program, start monitoring, and then load the file; program startup generates a lot of noise.

Maybe it's access denied, maybe it can't load a dll. Also double check that you're not loading veedub64 (the 64-bit version) on accident.

And yeah, that was pretty rude to people who are trying to help.

[Mole]

Did you try to remove any filter one by one till it will work??

Surely a script containing only
DirectShowSource ("Triple wall folding test tagged.avi")

should work, right? Then just add each filter till it refuse to load. This is very basic troubleshooting steps....

[clsid]

The new version probably uses safe DLL loading. Add the AviSynth plugin dir to %path% or use LoadPlugin with a full path in your script.