VirtualDub Access Violation opening ffdshow video via Avisynth

[mso6jx]

I thought I'd give VirtualDub2.1 a go - but immediately had problems, so had to revert to v2.0. My setup:

- Windows 10 Pro 22H2 19045.5247
- VirtualDub2.0 Build 44282
- Avisynth+ 3.7.3
- fddshow x64 v1.3.4533
- Lagarith Lossless Codec (1.3.27)

By way of example, an Avisynth script as simple as this fails to open in versions of 64bit VirtualDub2 NEWER than Build 44282:

source = AVISource("crash.avi")
Eval("source")

The message is:

File open error
Avisynth open failure:
System exception - Access Violation

Significantly, Lagarith videos do NOT provoke this issue.
The issue appears to be specific to videos saved in formats that Avisynth relies on ffdshow to decode - in my case, FFV1 files from deinterlaced VHS captures.
All versions of ffdshow (starting from the first one that enables Avisynth to decode FFV1) behave the same.

(As an aside, I did try replacing ffdshow with ffms2 or LSMASH as alternative FFV1 decoders, but my 10GB+ video files take FOREVER to be indexed, so I gave up!)

With my current setup (above) I can continue to work fine with FFV1 video in AVS scripts using ffdshow and VirtualDub2.0

However, there is a similar issue with VirtualDub2.0 - in fact, this was my original problem, and only while looking for a workaround did I stumble upon issue#1.
(It replicates in all earlier versions of VirtualDub2, all the way back to VirtualDub FilterMod.)

I have a complex Avisynth script that opens several large FFV1 videos, performs dozens of edits, and outputs a final version.
It works exactly as it should, but very slowly, rendering at just 9fps and using only 17% CPU.
To try to speed things up, I added a Prefetch() line to my script, and this did happily give me a four-fold speed increase to 36fps, using 90%+ CPU. But then I noticed a problem.

Issue#2 is this - when Prefetch() is included in the script, VirtualDub2.0 crashes when selecting a specific GUI menu.
It happens after opening the script when, prior to saving the video, I select "Video>Compression..."

Virtual2 Program Failure
Oops - VirtualDub has crashed. Details are listed below
etc
Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred at 7fffb10f52e9...
...reading address 0000000000000040...
...while querying video codec "ffdshow Video Codec" (compchoose.cpp:420)...
...while opening video codec with FOURCC "ffds" (compchoose.cpp:528)...
...while enumerating video codecs (compchoose.cpp:515).

(I haven't yet narrowed this one down to a simple reproducible example that I can share here in a readily describable fashion, sorry.)

My workaround is simple: set Compression *before* opening the script, not afterwards.
However, I can still only work with one script, and just once, before VirtualDub2 must be closed and relaunched.
Even opening the same script a second time in the same session is not possible.
By which I mean, select "File>Close video file" followed by "File>Open video file..." and select the same script.
An Access Violation error message pops up, and it's identical to the "Avisynth open failure" described in issue#1!

To be clear, all VirtualDub2 versions up to Build 44282 can't open my big script twice, and all later builds can't open my big script even once.

I'm mentioning both issues together here because of their "Access Violation" similarity, and an apparent common connection with ffdshow.
Perhaps there is a single underlying cause?

Sorry for the length of this post. Hope it wasn't TLDR, as they say ;o)

[Emulgator]

ffdshow v1.3.4533 is from 2014.
Well, this may not be the culprit, but indexing seems necessary to me,
because in the end you want to use Prefetch, so no linear aceess anymore.
I would just uninstall ffdshow and use VD's internal sourcefilter for FFV1.

[v0lt]

When you use AVISource, VFW decoders are used. But there is an incompatibility of modern software and ffdshow VFW decoder x64.
The installer ffdshow_rev4533_20140929_clsid_x64.exe writes about this in the component selection field.

In this case, Avisynth+ crashes. But this can happen with other modern software. Another example (https://github.com/v0lt/VirtualDub2/issues/1).

[mso6jx]

Understood, thank you. Basically, the issue I'm reporting here is already known about.

I see that Changes.txt in VirtualDub2.1 does explain that ff_vfw.dll is implicated in crashes "when opening the video compression selection window" and "when opening AVI files".

Well, I only installed ffdshow in the first place so that I could use FFV1 files in Avisynth+
My script opens six 2-hour source videos in VirtualDub2 in 20 seconds, whereas ffms2 and LSMASH take over 20 minutes to index just 1 video.

It seems my choices for this project are:
- abandon multi-threading and wait 5.6 hours for the edited video to save, instead of 1.4 hours
- convert the FFV1 source videos to larger Lagarith files
- just carry on, staying mindful of the limitations of my current setup when multi-threading Avisynth scripts handling FFV1 video.

[poisondeathray]

Another option is x264 (qp 0 for lossless) in a MOV/MP4 container . LSmashVideoSource for MOV/MP4 does not need to index and should open fast . If you use long GOP lossless, the compression ratio can be similar to FFV1 - it depends on the source material (usually a bit worse, sometimes better, but way better than lagarith).

[v0lt]

@mso6jx
Try using 32-bit tools.

[mso6jx]

Just for a moment, using 32-bit tools looked like the magic bullet I was hoping for...

Unfortunately, my script relies on interpolation, and more careful handling of colour spaces is needed in 32-bit than my cavalier "do everything in RGB" approach that I was getting away with in 64-bit.

While experimenting with 32-bit, colour space conversions mysteriously failed for no apparent reason and ever-increasing numbers of new access violations got my PC in such a state that absolutely everything looked broken, and I had to reboot!

[poisondeathray]

For the new problems, likely memory issues with x86 , complex scripts and multithreading will only make it worse . You can try SetMemoryMax(some value)

[filler56789]

Well, I only installed ffdshow in the first place so that I could use FFV1 files in Avisynth+

AFAIR, ffms2 can (or should) open FFV1 video,
regardless of the container :-/

[poisondeathray]

AFAIR, ffms2 can (or should) open FFV1 video,
regardless of the container :-/

It does, and he knows that - the downside was the indexing time


My script opens six 2-hour source videos in VirtualDub2 in 20 seconds, whereas ffms2 and LSMASH take over 20 minutes to index just 1 video.

[filler56789]

It does, and he knows that - the downside was the indexing time

You are right, today I am reading too fast :-/

[filler56789]

P.S.: On the other hand, the OP apparently didn't try DirectShowSource() or DSS2mod. 🤔

[poisondeathray]

P.S.: On the other hand, the OP apparently didn't try DirectShowSource() or DSS2mod. ��

He's got a complex script with many edits, so DirectShowSource probably isn't a good idea as it will likely cause other problems , mixed up frames, frame accuracy issues

DSS2mod is better in terms of those problems, but unfortunately it often drops some frames at the end . If anyone can fix that it would be a great alternative. DSS2Mod might be ok for some scenarios, but he's willing to endure the pains of using a lossless workflow and edits, so probably not a good idea for him in that case

[filler56789]

Well, he won't know or won't be sure until he tries...

IIRC, the main (if not the only) cause of the problems with DirectShowSource always were the B-frames...
and since FFV1 doesn't have B-frames, and since he's using the simplistic .AVI container...
And FWIW, LAV Video and LAV Splitter have always acted flawlessly in the few cases I had to use DirectShowSource some years ago.
We are not dealing with the ancient K-Lite Codec Packs and the annoying Haali Media Splitter anymore.😐

[poisondeathray]

Well, he won't know or won't be sure until he tries...

IIRC, the main (if not the only) cause of the problems with DirectShowSource always were the B-frames...
and since FFV1 doesn't have B-frames, and since he's using the simplistic .AVI container...
And FWIW, LAV Video and LAV Splitter have always acted flawlessly in the few cases I had to use DirectShowSource some years ago.
We are not dealing with the ancient K-Lite Codec Packs and the annoying Haali Media Splitter anymore.��

Good points and it could be worth trying

Personally, I'm always hesitant to do anything with DirectShowSource if there are edits or temporal filters. Linear access is mostly ok