ffmpeg / AviSynth+ AVS doesn't open in XMedia Recode

[thenicnic]

Hi there,

I'm struggling with a weird problem:
I have two systems, (8th Gen Intel Core i laptop and 6th Gen Core i desktop PC). The laptop runs Win 11 Pro (upgraded, everything did also work on Win 10 previously) and the desktop runs Win 10 Pro (fresh installation).

When I try to open the same AVS file in XMedia Recode 3.5.5.8 64bit, it loads on the laptop but not on the desktop. AviSynth+ 3.6.6.1 on both systems, same set of plugins.
XMedia Recode utilizes ffmpeg 5 which logs into AppData:

Working import log on laptop:
[NULL @ 0000025A6D902DC0] Opening 'C:\Users\N\Videos\VHS roh\QTGMC_MT_+_Crop.avs' for reading
[file @ 0000025A641D9240] Setting default whitelist 'file,crypto,data'
[avisynth @ 0000025A6D902DC0] Format avisynth probed with size=2048 and score=50
[avisynth @ 0000025A6D902DC0] avs_is_field_based: 0
[avisynth @ 0000025A6D902DC0] Before avformat_find_stream_info() pos: 0 bytes read:851 seeks:0 nb_streams:2
[avisynth @ 0000025A6D902DC0] All info found
[avisynth @ 0000025A6D902DC0] stream 0: start_time: 0 duration: 4220.32
[avisynth @ 0000025A6D902DC0] stream 1: start_time: 0 duration: 4220.32
[avisynth @ 0000025A6D902DC0] format: start_time: 0 duration: 4220.32 (estimate from stream) bitrate=0 kb/s
[avisynth @ 0000025A6D902DC0] After avformat_find_stream_info() pos: 0 bytes read:851 seeks:0 frames:3
[rawvideo @ 0000025A757A7240] PACKET SIZE: 557568, STRIDE: 1056
[rawvideo @ 0000025A757A7240] PACKET SIZE: 557568, STRIDE: 1056
[rawvideo @ 0000025A757A7240] PACKET SIZE: 557568, STRIDE: 1056
[rawvideo @ 0000025A757A7240] PACKET SIZE: 557568, STRIDE: 1056
[rawvideo @ 0000025A757A7240] PACKET SIZE: 557568, STRIDE: 1056
[AVIOContext @ 0000025A6CDECE40] Statistics: 851 bytes read, 0 seeks

Non-working import log on desktop:
[NULL @ 000001ABA3A96A80] Opening 'C:\Users\N\Desktop\QTGMC_MT_+_Crop.avs' for reading
[file @ 000001ABA0910400] Setting default whitelist 'file,crypto,data'
[avisynth @ 000001ABA3A96A80] Format avisynth probed with size=2048 and score=50
[AVIOContext @ 000001ABAA5B7C40] Statistics: 851 bytes read, 0 seeks


For any reason, it doesn't read the file input on the desktop. But strangely, MPC-HC and VirtualDub import the AVS without problems on the desktop!
I have no clue which component is the root of this issue
Log looks like AviSynth skips the interpretation of the file content ...

AVS file:
SetLogParams("dbg.txt", 4)
AviSource("video.avi").ConvertToYV12(Interlaced=Tr ue)

Crop(10, 6, -6, -42)
# crop (1) = left, (2) = top, (3) = right, (4) = bottom
# reference: 704 x 528
# [Breite-Px] / [Höhe-Px] * [PAR-Faktor = 1,092] = [Ziel-DAR]

AssumeTFF()
QTGMC(Preset="Slow", EdiThreads=8)

The log file isn't created when I try to import into XMedia Recode on the desktop but it is when I import into VirtualDub and MPC-HC. Contains only a warning with QTGMC though.

Has anybody a hint?

Thank you,

Nico

[ProWo]

Check if you have the same avisynth plugins in both computer.

[thenicnic]

Thanks, yes, that's what I meant with "same set of plugins" - I copied the directories from laptop to desktop.

[thenicnic]

Alright, issue fixed.
TLDR: Good old friend Microsoft Visual C++ Redistributable wasn't installed - at least not in the correct version.
Simple fix is download the most recent version from https://github.com/AviSynth/AviSynthPlus/releases with "_vcredist.exe", this has the cumulative (2015-2022) package included.

Instead of getting the correct registry paths for the plugins, the system lacking VC++ Redist just looked for the 'avisynth.dll' - which was weird to me, because the working system didn't accessed this file directly at all.

After parsing the AVS, there was a "mscvp80.dll" / "msvcr80.dll" loading on the working system which initially made me think of VC++ Redistributable.
And yes, of course AviSynth+ wasn't capable of doing it's job (registry lookup) because the whole program didn't run properly due the lack of the Redist.
I still don't know why this didn't affect the video playback. My assumption is that playback runs in x86 mode and the x86 VC++ may not have been missing, but no clue.

The buffer overflow at opening the AVS seems to be normal or at least not critical.