Batch Test AVISynth (avs) files

[tevert]

I have a video project I'm working on that has a little over 4000 AVISynth avs files that I'm using FFMPeg to convert into MPEG2 videos. As I have looked through the resulting m2v files I've found one or two out of the 4000 that converted with errors (video of red upside-down, mirror image, super condensed, unreadable text on a black background). EDIT: The fact that the error is upside down mirror image is just a curiosity of converting the error to MP2 and I shouldn't have mentioned it as it is just a red herring. These are in fact normal AVS errors like we always see when we do something wrong and display normal readable red on black errors if I play the offending AVS in MPlayer Classic.

Obviously checking 4000+ files manually in VirtualDUB or something, is a bit tedious to say the least. Is there a way to just batch test all the AVS files and then log, or show an error dialog, on which ones have a problem?

Thanks!

Tony

[guns1inger]

Nope.

With the exception of actual avisynth errors (red text on black background, usually), everything else would show as a successful encode. The fact that the image was upsidedown, mirrored etc is generally codec related, and not something inherent in the avisynth script or something that would trigger an error. While the outcome might not be what you want, technically there is no error to detect or report.

[tevert]

Thanks for the reply! For clarification, they are actual AVISynth errors and if I play the offending .avs file separately in MPlayer Classic, it does have the normal error as you described (red text on black background). The codec just makes them extra special.

So if that is the case does that make batch testing these possible somehow?

Tony

[guns1inger]

Upside down and mirrored video is not an avisynth issue unless you have coded some very specific effects and done something wrong. These are codec issues.

For anything that has actual avisynth error messages - avisynth has some very basic error code capabilities, including the ability to return a value from a script. In theory, if you can detect all possible error states, you could return a value that indicates something went wrong. I have never seen this implemented, and I have yet to see an encoder that can detect an actual error in a script.

[AlanHK]

One way to test several scripts at once is to make one like:

Import("a001.avs") ++\
Import("a002.avs") ++\
Import("a003.avs") ++\
Import("a004.avs") ++\
Import("a005.avs") ++\
Import("a006.avs") ++\
Import("a007.avs") ++\
Import("a008.avs") ++\
Import("a009.avs") ++\
Import("a010.avs")

You can then open that and test 10 at a time (or as many as you want), of course the more, the slower it will be to open.
That assumes they are all have the same size, framerate, audio channels.

If there is an error that aborts, then split the import list in half and isolate the error.

As for specific errors, like upside down, you should be able to find a pattern, something in the source files usually that is causing this.
If these are AVI files, use AVIcodec which can analyse and give a report on the basic specs of a whole folder of files at once, useful for tracking down oddballs.

[Gavino]

Is there a way to just batch test all the AVS files and then log, or show an error dialog, on which ones have a problem?

For each script xxx.avs, create a wrapper file containing:

script = "xxx.avs"
log = "C:\avslog.txt"  # or some filename of your choice
try { Import(script) }
catch (err) {
  WriteFileStart(BlankClip(), log, "script", """ ": " """, "err", append=true)
}

Then if you use the wrapper files instead of the original scripts, you will get an message logged to the log file for each script that produces an error.
You can write a batch script to create the wrapper files.

[tevert]

For each script xxx.avs, create a wrapper file containing:

script = "xxx.avs"
log = "C:\avslog.txt"  # or some filename of your choice
try { Import(script) }
catch (err) {
  WriteFileStart(BlankClip(), log, script, """ ": " """, err, append=true)
}

Then if you use the wrapper files instead of the original scripts, you will get an message logged to the log file for each script that produces an error.
You can write a batch script to create the wrapper files.

Gavino that is exactly what I'm looking for.

I totally missed the try/catch feature in AVISynth. Since I'm batch generating these avs files in the first place, I will put the try/catch log sequence right in the AVS files.

It worked perfectly in the test AVS file I built.

Thanks so much Gavino, this completely solves my problem. (And thank you guns1inger and AlanHK for your assistance too!)

Tony

[Gavino]

Since I'm batch generating these avs files in the first place, I will put the try/catch log sequence right in the AVS files.

That's obviously more convenient, but it's worth noting that if the generated script contains a syntax error (eg misplaced comma) rather than a semantic error (eg invalid arguments to a function), it will fail before the try/catch is executed and nothing will be logged. Putting the 'real' script inside Import gets round that.

EDIT: If you've got it working, you've probably already corrected this, but I missed the quotes around "script" and "err" in the WriteFileStart call earlier - now edited to be correct.

[tevert]

That's obviously more convenient, but it's worth noting that if the generated script contains a syntax error (eg misplaced comma) rather than a semantic error (eg invalid arguments to a function), it will fail before the try/catch is executed and nothing will be logged. Putting the 'real' script inside Import gets round that.

Hmm good point to consider, and that is true--I proved that this is the case.

EDIT: If you've got it working, you've probably already corrected this, but I missed the quotes around "script" and "err" in the WriteFileStart call earlier - now edited to be correct.

Ahh. It was correctly logging errors only on AVS files when there was an issue with the AVS, but the logged errors were not particularly useful--basically just stating that there was a syntax error (now I know why). I was only a little bit disappointed, because all I needed was to know that AVS #2733 was causing a problem, and I could deal with it from there.

But... with "err" in quotes, it makes the logged error messages actually useful and informative! Wow! (I'm starting to better understand that command: coming from other programming languages it is an adjustment to put variables in quotes! )

Thanks again!

Tony

[Gavino]

I'm starting to better understand that command: coming from other programming languages it is an adjustment to put variables in quotes!

That's a peculiarity of the WriteFileStart command which is often a source of confusion (for me too, as you saw!). It makes more sense in the case of the related WriteFile function, where the value is an expression that gets re-evaluated on every frame. For WriteFileStart (and WriteFileEnd), it could (should?) have been made to take the actual value rather than an expression - but I suppose the author wanted to keep the interface consistent.