FFmpegSource

[Boulder]

The method for adding Unicode support to DGIndexNV also works with other apps, I use it myself with VirtualDub2 and avs2yuv64 to be able to use Unicode characters in paths. See "UTF-8 Notes.txt" in the DGIndexNV package.

[StvG]

The AvsPmod from post #2794 (https://filebin.net/43ggbshts33bxncf work normally with ffms2_r1386. After, I checked the older ver r1369 and it works with Megui, AvsPmod 2.7.5.5 but can't use with your AvsPmod shared
https://imgur.com/a/i9F2OYO

The older ffms2 r1369 works with Megui and AvsPmod 2.7.5.5 because you set the correct system locale. For example, set Bulgaria for system locale and you will see how r1369+Megui/AvsPmod 2.7.5.5 will fail with your file but my test AvsPmod+r1386 is working. That's the whole point of the unicode support - to be not dependent on the system locale.

[kedautinh12]

The older ffms2 r1369 works with Megui and AvsPmod 2.7.5.5 because you set the correct system locale. For example, set Bulgaria for system locale and you will see how r1369+Megui/AvsPmod 2.7.5.5 will fail with your file but my test AvsPmod+r1386 is working. That's the whole point of the unicode support - to be not dependent on the system locale.

No, I get back and reset before this test and r1369 work perfectly with English (United States)

[StvG]

No, I get back and reset before this test and r1369 work perfectly with English (United States)

What no? Did you read what I wrote? Am I writing in a non-understandable way?

It's second time I write exactly what you should do to see that r1369+AvsPmod 2.7.5.5/Megui is broken but you do something completely different and then you say: "No...".
The first time I explicitly asked you to test virtualdub2/avsmeter64 but you tested Megui.

I'm talking on a wall. Basta.


For anyone else having issues with file names and r1386 - test the script with virtualdub2/avsmeter64/ffmpeg. If you still have issues with these programs report here. If you don't have issues with these but you have issue with other program you use to open the avs script (AvsPmod/Megui...) do not complain here, complain to devs of the used program.

[kedautinh12]

What no? Did you read what I wrote? Am I writing in a non-understandable way?

It's second time I write exactly what you should do to see that r1369+AvsPmod 2.7.5.5/Megui is broken but you do something completely different and then you say: "No...".
The first time I explicitly asked you to test virtualdub2/avsmeter64 but you tested Megui.

I'm talking on a wall. Basta.


For anyone else having issues with file names and r1386 - test the script with virtualdub2/avsmeter64/ffmpeg. If you still have issues with these programs report here. If you don't have issues with these but you have issue with other program you use to open the avs script (AvsPmod/Megui...) do not complain here, complain to devs of the used program.

Ok, I think you said I changed the system locate to Vietnamese before is the correct system locate so I said to you that I changed back to English (United States) before the test. And yeah, Bulgari has correctly broken to r1369 but I changed it to Vietnamese and it's working again. I think some system locale doesn't work correctly with Megui and AvsPmod when use r1369

Edit: With Vietnamese system locate, r1386, virtualdub2 from here (https://forum.doom9.org/showthread.php?p=1993799#post1993799), I got error too. I open .avs file via virtualdub2
https://i.imgur.com/vc32ZKF.png

Edit 2: avsmeter too
https://i.imgur.com/CniZUw5.png

Edit 3: FFMPEG too
https://i.imgur.com/8SKOzac.png

[kedautinh12]

The method for adding Unicode support to DGIndexNV also works with other apps, I use it myself with VirtualDub2 and avs2yuv64 to be able to use Unicode characters in paths. See "UTF-8 Notes.txt" in the DGIndexNV package.

I tried with your suggestion but Megui and AvsPmod don't work with r1386

[StvG]

Ok, I think you said I changed the system locate to Vietnamese before is the correct system locate so I said to you that I changed back to English (United States) before the test. And yeah, Bulgari has correctly broken to r1369 but I changed it to Vietnamese and it's working again. I think some system locale doesn't work correctly with Megui and AvsPmod when use r1369

Edit: With Vietnamese system locate, r1386, virtualdub2 from here (https://forum.doom9.org/showthread.php?p=1993799#post1993799), I got error too. I open .avs file via virtualdub2


Edit 2: avsmeter too


Edit 3: FFMPEG too



Make sure you're using r1386 - https://ibb.co/4mSnx3f

[kedautinh12]

I'm sure:
https://i.imgur.com/quf6PVZ.png

[kedautinh12]

Ok, it's works now with check a box Beta: Use Unicode UTF-8 for worldwide language support in Megui and AvsPmod
https://i.imgur.com/J3j1mNf.png

Edit: but I can't use same way with Virtualdub2 and avsmeter64
Edit 2: My mistake when I save script .avs as ANSI so Virtualdub2 and avsmeter64 don't work. A way above only use with Megui and AvsPmod don't support utf8

[StvG]

r1386 should work without the check. Can you share the output of avsmeter64 -avsinfo?

[kedautinh12]

r1386 should work without the check. Can you share the output of avsmeter64 -avsinfo?

https://jumpshare.com/s/5UgR7DiSNYzLfFeJp0he

[StvG]

Come on... we're talking about UTF-8 and you saved your scrtipt (.avs) as ANSI? It's no surprise all apps avsmeter64/ffmpeg/virtualdub2 complains.

Try this test (https://filebin.net/jjekjv1l9mkleevp). Just open test.bat and you should have the video playing.

[kedautinh12]

Ok, when i change code to utf8 in avs file. VirtualDub2/AVSMeter/FFMPEG work without check beta box

[Emulgator]

StvG, many thanks !
Region setting: Deutsch, UTF-8 support unticked.
Your UTF-8 test.bat calling UTF-8 script calling ffplay on Vietnamese-named video ác quá.mkv with source filter ffms2.dll version 1386 works here.
P.S. And AvsPmod 2.7.5.5 fails and 2.7.3.6M works on the same script.
P.P.S. And the new AvsPmod 2.7.5.6 works. Thanks to gispos !

[StvG]

ffms2_r1387 (https://codeberg.org/StvG/ffms2/releases/tag/r1387)

[FranceBB]

ffms2_r1387 (https://codeberg.org/StvG/ffms2/releases/tag/r1387)

Seems to be working just fine with Avisynth + x264 + FFMpeg AAC + MP4Box:

https://i.imgur.com/HOTBnsJ.png

[flossy_cake]

ffms2_r1387 (https://codeberg.org/StvG/ffms2/releases/tag/r1387)

Not working for me unfortunately:

https://i.ibb.co/GHTMyCR/Untitled-1.png

The latest "official" version here (https://github.com/FFMS/ffms2/releases/tag/2.40) is working for me, but suffers the issue with interlaced MPEG2 where it doesn't properly obey the repeat field flags, resulting in broken output like random frames having wrong field order and wrong frame pacing type visual effects. It's fine for x264/x265 progressive stuff though, just not NTSC DVDs which unfortunately is most of what I'm using Avisynth for.

[StvG]

@flossy_cake, mpc-hc 2.1.2 (https://github.com/clsid2/mpc-hc/releases/tag/2.1.2) works for me with the following script:

FFVideoSource("1080p.mkv")

Run avsmeter64 with the script to see if there is error.

You can be more specific. For example, what's the used script so one could reproduce the issue.

[kedautinh12]

Did you update to latest the vc++?
https://github.com/abbodi1406/vcredist/releases

[flossy_cake]

@flossy_cake, mpc-hc 2.1.2 (https://github.com/clsid2/mpc-hc/releases/tag/2.1.2) works for me with the following script:

FFVideoSource("1080p.mkv")


Thanks that works for me too. So I guess it's somehow audio related since ffms2() doesn't work for me.

Unfortunately interpretation of MPEG2 repeat field flags is still wrong compared to LWLibav and DGDecode which both get it right. Here (https://drive.google.com/file/d/1QaVeLqnl0oOlclrb89O9NrkcWDGvKpzK/view?usp=sharing) is a test clip, try:


FFVideoSource("C:\S01E02_cut.mkv", rffmode=1)
Bob()


Placing an AssumeTFF/AssumeBFF before the Bob doesn't fix it since FFVideoSource's interpretation of the repeat field flags appears to be dynamically wrong -- some frames are ok, others are not.

Compare with:


LWLibavVideoSource("C:\S01E02_cut.mkv", repeat=true)
Bob()



edit: I should mention that clip is not an ideal test clip as it's been remuxed from the DVD VOB, and something about doing that seems to trip up certain decoders for that particular DVD. I can upload the full 1GB VOB if you want to see how the repeat field flags are interpreted correctly by LWLibav and DGDecode.

edit: was able to make a short VOB clip using DVDShrink - uploaded here (https://drive.google.com/file/d/1mbHHgNyNFJdFPZDcJbJ0USK6d47HAKDR/view?usp=sharing). LWLibAv and DGDecode play it correctly while FFMS does not, so I think that would be the ideal test file.

edit: if I had to guess what is going on, perhaps FFMS is obeying the repeat field flags but just not getting the field order right. There is a table here (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/32) which shows how repeat fields should be handled to produce the final presented frames (the bottom row marked "decode frame" is what FFMS should output).

If the issue is occurring within the ffmpeg binaries (https://ffmpeg.org/doxygen/trunk/vf__repeatfields_8c_source.html) used by FFMS then I'm guessing it's probably not something that could be fixed in the avisynth plugin anyway.

[hello_hello]

Not working for me unfortunately

I have the same issue with the 64 bit versions of ffms2_r1386 and ffms2_r1387. I haven't tested the 32 bit versions yet.

FFMS2 with audio enabled (or FFAudioSource) produces an access violation error message (AvsPmod). I assumed it was a problem relating to running Avisynth in Wine on Linux originally, but I've also tested it on Windows 11 with the same result.

https://imgur.com/xe28LfT.png

[StvG]

@flossy_cake, thanks for the samples. rffmode=0 is ok but rffmode=1 gives different results than lwlibavvideosource. Have to take a look.

@hello_hello, I have no issues with the following:

FFVideoSource("test.mkv")

a=FFMS2("test.mkv", atrack=-1)
#FFAudioSource("test.mkv")
AudioDub(a)
Waveform()

You can share a sample so I can reproduce the issue.

[kedautinh12]

I follow step by step in utf8.txt (the file in DGDemux) with ffms r1386. Some step like run regedit file and change name DGIndexNVutf8 manifest file to Meguiuft8 manifest (sorry i can't remember exactly file name cause i don't near the PC now) and put same folder with megui.exe. But Megui.exe don't work with ffms2 r1386 when try index file. I tried it with AVSPmod but it's don't work too. Lately, I tried this step and it's work without change name of utf8 file
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/49#issuecomment-1807345434

[kedautinh12]

Megui 2944 x64 don't work with ffms2 r1386 and L-SMASH-Works 20231106 1147.0.0.0 but it's work with ffms r1387 and L-SMASH-Works 20231117 1156.0.0.0

Here my Megui 2944 (https://drive.google.com/file/d/1Mv19aMfGD-6zJc1MrDhKcGm39VhiDhGT/view) you can try download from offical page but it's only work with avs+ 3.5 and you need MeGUI AvisynthWrapper from Pinterf to work with avs+ >=3.6 while my link already have this

[kedautinh12]

1, Megui 2944 x64
2, file name ác quá (https://drive.google.com/file/d/1VAcp5b28eCjlqwZoNxd0z3Ge4R3pRbJK/view?usp=drivesdk)
3, Megui same notification error with AVSPmod when try indexing with ffms r1386
https://forum.doom9.org/showthread.php?p=1993755#post1993755

I thought you will fix easily with more info :D

[flossy_cake]

@flossy_cake, thanks for the samples. rffmode=0 is ok

rffmode=0 in my experience is not usable with NTSC DVDs containing repeat field flags either. It seems the only way to play back NTSC DVDs which use repeat fields flags is to obey those flags. DG talks about it here (https://www.rationalqm.us/dgmpgdec/DGIndexManual.html#FieldOp):


Ignore Pulldown Flags - The pulldown flags are ignored. This allows one to obtain the raw encoded MPEG pictures, with no repeated fields. However, because repeated fields intended for display are ignored and not displayed, the resulting frame rate may differ from the source frame rate. It may even vary throughout the clip, due to irregular patterns of pulldown flags. If the pulldown is irregular, use of this option will cause the audio-video sync to change at different parts of the clip, and most likely sync will not be acceptable. This option is mostly intended for power users, who would use it as a diagnostic aid for inspecting the encoded MPEG pictures. Although this option ignores the flags, they are still stored in the D2V file although DGDecode will also ignore them.


Here (https://drive.google.com/file/d/1xz_WEX36iv8tpC18zR8e8-etGwtqfuVb/view?usp=drive_link) is a longer clip from an NTSC DVD with repeat field flags where you should see the issue -- it wasn't obvious on the previous Lain clip as there weren't any audio cues correlating to anything on screen, but it was likely playing the video at the wrong rate due to ignorance of repeat field flags. If you leave the video playing for about 1 minute after the intro it should be out of sync by then. I was using:


video = FFVideoSource(clip, rffmode=0)
audio = FFAudioSource(clip)
AudioDub(video, audio)

[flossy_cake]

This may help with debugging... I saw Lwlibav includes the frame properties _EncodedFrameTop and _EncodedFrameBottom which say which source frame was used to generate the top and bottom fields of the current_frame.

Take this frame for example:

https://c.l3n.co/i/slQcjC.png

It says the top field of this frame was from frame 2475 and bottom field was from 2476. 2475 comes before 2476 so it means this particular frame should be top field first. I suspect the issue is that occasionally FFMS2 is getting this wrong and puts in the wrong location. But FFMS doesn't populate any frame properties from this clip. I looked at FFInfo() but it didn't show more useful info.

[kedautinh12]

I remember ffms2 already had frame properties

[flossy_cake]

I remember ffms2 already had frame properties

Sorry yes, StvG's version does -- the _FieldBased property:


_FieldBased
0=frame based (progressive), 1=bottom field first, 2=top field first


There is also


GetParity (clip, int n)
Returns true if frame n is top field first of frame-based clip


Comparison LWLibAV vs FFMS: https://drive.google.com/u/0/uc?id=1nbX3ZnaiVfg3JbAa0tOqb4pFuyxG80LS&export=download

https://c.l3n.co/i/sSpXlH.png

Script used to render the above clip:


file = "c:\S01E02_cut.mkv" # https://drive.google.com/u/0/uc?id=1QaVeLqnl0oOlclrb89O9NrkcWDGvKpzK&export=download

lwlav = LWLibavVideoSource(file, repeat=true)
lwlav = lwlav.Trim(938, 1042) ++ lwlav.Trim(2606, 2684) ++ lwlav.Trim(2779,2915)
lwlav = lwlav.ScriptClip("""
if (propGetAny("_FieldBased")==0){fb="progressive"}
if (propGetAny("_FieldBased")==1){fb="BFF"}
if (propGetAny("_FieldBased")==2){fb="TFF"}
if (GetParity(current_frame)==true){gp="TFF"}
if (GetParity(current_frame)==false){gp="BFF"}
SubTitle("Correct" + "\n"
\ + "_Fieldbased: " + fb + "\n"
\ + "GetParity(): " + gp
\ , align=5, text_color=$00FF00, lsp=0, size=30)
\ .SubTitle("LWLibavVideoSource(file, repeat=true)", size=30)
\ """)
lwlav = lwlav.Bob()

ffvs = FFVideoSource(file, rffmode=1)
ffvs = ffvs.Trim(938, 1042) ++ ffvs.Trim(2606, 2684) ++ ffvs.Trim(2779,2915)
ffvs = ffvs.ScriptClip("""
if (Defined(propGetAny("_FieldBased"))){
if (propGetAny("_FieldBased")==0){fb="progressive"}
if (propGetAny("_FieldBased")==1){fb="BFF"}
if (propGetAny("_FieldBased")==2){fb="TFF"} }
else { fb = "undefined" }
if (GetParity(current_frame)==true){gp="TFF"}
if (GetParity(current_frame)==false){gp="BFF"}
SubTitle("Incorrect" + "\n"
\ + "_Fieldbased: " + fb + "\n"
\ + "GetParity(): " + gp
\ , align=5, text_color=$FF0000, lsp=0, size=30)
\ .SubTitle("FFVideoSource(file, rffmode=1)", size=30)
\ """)
ffvs = ffvs.Bob()

StackHorizontal(lwlav, ffvs)



__________________________________________________________________________

P.S I deleted my previous 2x2 tiled comparison video as it was wrong because according to GetParity():

FFMS2(rffmode=1) # some frames are TFF, others BFF
FFMS2(rffmode=1).AssumeTFF() # all frames TFF
FFMS2(rffmode=1).AssumeBFF() # all frames BFF

So my comparison script was wrong there, please ignore that (I've deleted it).

I suppose it's still useful for showing that FFMS2(rffmode=1).AssumeBFF() doesn't resolve the issue since doing a Bob() on that still shows frames presented in the wrong order.

[flossy_cake]

By the way it seems the _FieldBased prop is unreliable in both LWLibav & FFMS2 - this frame for example is clearly not progressive despite being flagged as such:


https://a.l3n.co/i/sScJPz.png

edit: now that I look at the actual definition of FieldBased, perhaps none of the frames should be flagged as _Fieldbased=0 (progressive). Fieldbased I think is what you get after a SeparateFields() - every frame is now a single field, and this clip isn't that. Maybe it's referring to what the decoder sees internally, not really sure.

There is a field-based flag, but contrary to what you might expect, this flag is not related to interlaced video. In fact, all video (progressive or interlaced) is frame-based, unless you use AviSynth filters to change that. There are two filter who turn frame-based video into field-based video: SeparateFields and AssumeFieldBased.

Also I tried a ScriptClip ComplementParity workaround for FFMS2 and that still produced fields in nonlinear order (visible by framestepping through the bobbed output).

Perhaps this wasn't much of an issue in the past as most people do their IVTC/deinterlacing at half rate so half the frames get thrown away anyway and that reduces or eliminates the issue.

[real.finder]

in DVD case it's kinda complicated, back then this is https://github.com/Asd-g/MPEG2DecPlus/issues/9#issuecomment-1114307244 what I see do the job in these cases, you can read all comments if you like

[StvG]

By the way it seems the _FieldBased prop is unreliable in both LWLibav & FFMS2 - this frame for example is clearly not progressive despite being flagged as such:


https://a.l3n.co/i/sScJPz.png

edit: now that I look at the actual definition of FieldBased, perhaps none of the frames should be flagged as _Fieldbased=0 (progressive). Fieldbased I think is what you get after a SeparateFields() - every frame is now a single field, and this clip isn't that. Maybe it's referring to what the decoder sees internally, not really sure.



Also I tried a ScriptClip ComplementParity workaround for FFMS2 and that still produced fields in nonlinear order (visible by framestepping through the bobbed output).

Perhaps this wasn't much of an issue in the past as most people do their IVTC/deinterlacing at half rate so half the frames get thrown away anyway and that reduces or eliminates the issue.

Try this version (https://filebin.net/ygbp9loimbe82o80).

I probably should remove _FieldBased when rffmode > 0. The frame you showed is constructed from fields of one frame marked as interlaced (bottom first) and one frame marked as progressive.

[flossy_cake]

Try this version (https://filebin.net/ygbp9loimbe82o80).


Oh my gosh you bloody beauty! Rffmode 1 appears to be working perfectly, and the Avisynth parity (getparity) stays locked for the whole clip which avoids potentially confusing any downstream deint/IVTC filters. Fantastic, really happy with this.

:thanks:

However I must use a different filter for audio otherwise FFMS crashes with that same message I posted earlier (hello_hello having same issue it seems).

Previously I wrote that using FFAudioSource instead of FFMS2 avoided the crash, but it turns out I had a different dll version that time - v1349 according to file properties. So v1349 doesn't crash, but your two most recent betas of v1387 are both crashing. Hopefully that offers a clue. I have tried the suggestions here (https://forum.doom9.org/showthread.php?p=1994336#post1994336) and here (https://forum.doom9.org/showthread.php?p=1994461#post1994461) without effect.

[flossy_cake]

Try this version (https://filebin.net/ygbp9loimbe82o80).

Hmm, seems to crash when multithreading is enabled:

ffms2(clip, rffmode=1) # or FFVideoSource
bob() # remove this line = no crash
prefetch(4)


Sidenote: must remember to delete .ffindex files before trying a new dll version otherwise the old index files will be used by the new dll, and this was creating some bugged behaviour for me.

[StvG]

Hmm, seems to crash when multithreading is enabled:

ffms2(clip, rffmode=1) # or FFVideoSource
bob() # remove this line = no crash
prefetch(4)


Sidenote: must remember to delete .ffindex files before trying a new dll version otherwise the old index files will be used by the new dll, and this was creating some bugged behaviour for me.

I can reproduce this crash and will take a look later.

About the audio. As I wrote I cannot reproduce the issue. You can share a sample that causes the crash and the used script.

[flossy_cake]

About the audio. As I wrote I cannot reproduce the issue. You can share a sample that causes the crash and the used script.

For me it's crashing on all files, eg.

file = "C:\S01E02_cut.mkv" #https://drive.google.com/u/0/uc?id=1QaVeLqnl0oOlclrb89O9NrkcWDGvKpzK&export=download

video = FFVideoSource(file, rffmode=1)
audio = FFAudioSource(file, track=-1)
AudioDub(video, audio)

Must be something system specific - here are my installed C++ runtimes

https://a.l3n.co/i/sMSvZ7.png

https://a.l3n.co/i/sMnItM.png

edit: also tried moving all dlls out of /plugins/ folders leaving only ffms2

[hello_hello]

@hello_hello, I have no issues with the following:

FFVideoSource("test.mkv")

a=FFMS2("test.mkv", atrack=-1)
#FFAudioSource("test.mkv")
AudioDub(a)
Waveform()

You can share a sample so I can reproduce the issue.

Sorry about the slow reply. Here's a small sample if it's still helpful.

audio test.mkv (https://files.videohelp.com/u/210984/audio%20test.mkv)

[StvG]

@flossy_cake, the crash isn't related to the Redistributable Runtimes.
@hello_hello, thanks for the sample. I have no issues with it and the showed script (AvsPmod used). What app did you use to run/open the script?

Anyway, try ffms2_test1 (https://filebin.net/v6l7es0xouzs166j).

[hello_hello]

I'm using AvsPmod, but I get the same error when I open the script with MPC-HC. It's happening with Avisynth running in Wine and also on Windows 11 in VirtualBox.
I haven't let Windows update itself for a while. I'll do that later and report back if it makes a difference.

https://imgur.com/ApmC3Gj.png

ffms2_test1 produces a different error message, unfortunately, but it's the same for both Wine and Windows and AvsPmod and MPC-HC.

https://imgur.com/8w5CCrL.png

Edit: I also tried replacing 64 bit Avisynth.dll 3.7.2 with version 3.7.3, but nothing changed.

Edit: I have the 32 bit version of Avisynth+ installed in a 32 bit Wine prefix (I don't have it installed on Windows) and FFMS2 r1387 produces the same access violation error message. The video on it's own is still okay.

https://imgur.com/SnS7eoV.png

[StvG]

@hello_hello, with ffms2_test1 I get the same error ("... zero size audio"). Try ffms2_test2 (https://filebin.net/lkjey5n6ocu2c4jg).

[hello_hello]

Did you use latest vc++ (https://github.com/abbodi1406/vcredist/releases)?

I have now but it made no difference. I also installed the latest updates for Windows 11. I'd forgotten how slow and painful that process is.

As it didn't solve the problem I thought I'd try some older FFMS2 versions. Fortunately I didn't have to go back far. 64 bit r1369 works normally in Wine and on Windows 11. 32 bit r1369 works normally in a 32 bit Wine prefix.
It's a mystery.....

https://imgur.com/Gd2chi5.png

[kedautinh12]

r1387 work with me too

[hello_hello]

@hello_hello, with ffms2_test1 I get the same error ("... zero size audio"). Try ffms2_test2 (https://filebin.net/lkjey5n6ocu2c4jg).

Thanks, but unfortunately that takes me back to the access violation error. It's still happening in both Wine and Windows 11.
I've even tried completely emptying the auto-loading plugins folder (aside from FFMS2) just in case.... but it didn't help.

Cheers.

[kedautinh12]

You can check with Dependencies, drag and drop ffm2.dll to app
https://github.com/lucasg/Dependencies/releases

[StvG]

Thanks, but unfortunately that takes me back to the access violation error. It's still happening in both Wine and Windows 11.
I've even tried completely emptying the auto-loading plugins folder (aside from FFMS2) just in case.... but it didn't help.

Cheers.

You're using not very recent avs+? Try this ffms2_test3 (https://filebin.net/itul9nrgrswy8816).

You can check with Dependencies, drag and drop ffm2.dll to app
https://github.com/lucasg/Dependencies/releases

It's not related to the dependencies. If some dependency is missing the error will be that the function ffms2 is not found.

[hello_hello]

You're using not very recent avs+? Try this ffms2_test3 (https://filebin.net/itul9nrgrswy8816).

Success!!!! Thank you.

I'm using Avisynth+ 3.7.2, because I haven't been motivated to replace DitherTools yet, but I did try 3.7.3 and it produced the same access violation error.

If I was to ask you what the problem was, would I understand the answer?

Thanks again!

[StvG]

Success!!!! Thank you.

I'm using Avisynth+ 3.7.2, because I haven't been motivated to replace DitherTools yet, but I did try 3.7.3 and it produced the same access violation error.

If I was to ask you what the problem was, would I understand the answer?

Thanks again!

For r1369 when I initially added audio channel mask I added similar check to this one (https://github.com/FFMS/ffms2/pull/421/commits/f12c48a2a903e32093d8f3f0feeb446057b0a11a) - if the new audio property is not supported by avs+ (not very recent version) it would not add such property. After the official ffms2 added audio channel mask (https://github.com/FFMS/ffms2/commit/ef243ab40b8d4b6d18874c6cef0da1a2f55a6a45) (without such check if avs+ supports channel mask), I removed my patch for channel mask. Now I have to add again this check.

ffms2_test1 is using different ffmpeg libraries and that's why the error was different. It's ffmpeg culprit.

About DitherTools - you can try this one (https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/master/plugins64+/dither.dll?ref_type=heads) with the newer avs+.

[hello_hello]

For r1369 when I initially added audio channel mask I added similar check to this one (https://github.com/FFMS/ffms2/pull/421/commits/f12c48a2a903e32093d8f3f0feeb446057b0a11a) - if the new audio property is not supported by avs+ (not very recent version) it would not add such property. After the official ffms2 added audio channel mask (https://github.com/FFMS/ffms2/commit/ef243ab40b8d4b6d18874c6cef0da1a2f55a6a45) (without such check if avs+ supports channel mask), I removed my patch for channel mask. Now I have to add again this check.

Well that's annoying because as I wrote in an earlier post I checked it with Avisynth+ 3.7.3 but it still produced the same error. Well.... apparently I didn't... because I tried again and r1387 works fine with Avisynth+ 3.7.3. Maybe I did something silly like replace Avisynth.dll in the wrong Wine prefix or replaced it while AvsPmod was still open or something..... sorry about that.

About DitherTools - you can try this one (https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/master/plugins64+/dither.dll?ref_type=heads) with the newer avs+.

Cheers. I'll update Avisynth+ now.

[kedautinh12]

About DitherTools - you can try this one (https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/master/plugins64+/dither.dll?ref_type=heads) with the newer avs+.

This dither for 64 bit, you need ask Asd-g to support 32 bit with newer avs+ too, @hello_hello
https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/issues

[StvG]

ffms2_r1390 (https://codeberg.org/StvG/ffms2/releases/tag/r1390)