AviSynth+ thread Vol.2

[flossy_cake]

Hey I was wondering where is the best place to get the latest Avisynth builds from?

I saw it referenced on official GitHub here (https://github.com/AviSynth/AviSynthPlus/actions/runs/7531059881/job/20498782095) but no download links.

I saw this (https://gitlab.com/uvz/AviSynthPlus-Builds) repo which has download links but I don't know who's making the builds.
edit: oh I just saw pinterf is putting them on gdrive in post#1 :thanks:

edit: looking at avisynth_updater.bat (https://gitlab.com/uvz/AviSynthPlus-Builds/-/blob/main/avisynth_updater.bat?ref_type=heads) it seems I just need to put Avisynth.dll and DevIL.dll in Windows/System32, and the rest in /plugins64+ folder, have I got that right?

[kedautinh12]

Hey I was wondering where is the best place to get the latest Avisynth builds from?

I saw it referenced on official GitHub here (https://github.com/AviSynth/AviSynthPlus/actions/runs/7531059881/job/20498782095) but no download links.

I saw this (https://gitlab.com/uvz/AviSynthPlus-Builds) repo which has download links but I don't know who's making the builds.
edit: oh I just saw pinterf is putting them on gdrive in post#1 :thanks:

edit: looking at avisynth_updater.bat (https://gitlab.com/uvz/AviSynthPlus-Builds/-/blob/main/avisynth_updater.bat?ref_type=heads) it seems I just need to put Avisynth.dll and DevIL.dll in Windows/System32, and the rest in /plugins64+ folder, have I got that right?

pinterf was released beta ver at this thread, and the repo belongs to Asd-g

[tebasuna51]

edit: looking at avisynth_updater.bat (https://gitlab.com/uvz/AviSynthPlus-Builds/-/blob/main/avisynth_updater.bat?ref_type=heads) it seems I just need to put Avisynth.dll and DevIL.dll in Windows/System32, and the rest in /plugins64+ folder, have I got that right?

"Avisynth.dll and DevIL.dll in Windows/System32" OK for dll's 64 bits

"the rest in /plugins64+ folder" or in other folder defined in the register, check the register commands. I use C:\Portable\Avs\AVSPLUS370_x64\plugins

[pinterf]

Hey I was wondering where is the best place to get the latest Avisynth builds from?

I saw it referenced on official GitHub here (https://github.com/AviSynth/AviSynthPlus/actions/runs/7531059881/job/20498782095) but no download links.

I saw this (https://gitlab.com/uvz/AviSynthPlus-Builds) repo which has download links but I don't know who's making the builds.
edit: oh I just saw pinterf is putting them on gdrive in post#1 :thanks:

edit: looking at avisynth_updater.bat (https://gitlab.com/uvz/AviSynthPlus-Builds/-/blob/main/avisynth_updater.bat?ref_type=heads) it seems I just need to put Avisynth.dll and DevIL.dll in Windows/System32, and the rest in /plugins64+ folder, have I got that right?
I meant I've fixed on the git repo, in the source code. I didn't have time to assemble a test build (binary). This time the above mentioned asd-g builds can help you probably.

[hello_hello]

I seem to have stumbled upon a ConvertToYUY2 oddity.
Avisynth+ 64 bit, r4035 (Clang, I think).

ColorBars().KillAudio()
ConvertToYUY2()

https://i.ibb.co/g6sY29Q/YUY2.png

This is okay.

ColorBars().KillAudio()
ConvertToYV16()
ConvertToYUY2()

https://i.ibb.co/7tHVy17/YV16-to-YUY2.png

[pinterf]

I seem to have stumbled upon a ConvertToYUY2 oddity.
Avisynth+ 64 bit, r4035 (Clang, I think).

ColorBars().KillAudio()
ConvertToYUY2()

This is okay:

ColorBars().KillAudio()
ConvertToYV16()
ConvertToYUY2()


Thanks for the report. Afaik there is direct rgb -> yuy2 conversion. The conversion code or the usage of color conversion matrix must be wrong there.

EDIT: there was a bug in Studio Range RGB (_ColorRange = 1) to YUY2 conversion. (ColorBars outputs studio range sample)
Regression since Avisynth+ 3.7.3post test 4 (20231019 - r4013)
(this one:
- Studio RGB (limited) range will now be recognized (through _ColorRange=1) and utilized in
conversions from RGB, such as in GreyScale, ConvertToY, ConvertToYUVxxx.
When input or output would require it, rgb offset of 16 (or scaled equivalents) is used
for supporting limited range rgb (similar to Y offset=16 used at limited range YUV conversions)
)

[flossy_cake]

There's also an issue with Text() colour in YV12 in pinterf's gdrive build 4035 (https://drive.google.com/uc?export=download&id=1yuiF6rnphnfpBoZGFTsT9vKPGiZxbGCX):


ColorBars().ConvertToYV12().Trim(0, 300)
Text("Red text", font="Terminus", bold=true, size=20, text_color=$FF0000, align=5, lsp=0)
Text("\n\nGreen text", font="Terminus", bold=true, size=20, text_color=$00FF00, align=5, lsp=0)
Text("\n\n\n\nBlue text", font="Terminus", bold=true, size=20, text_color=$0000FF, align=5, lsp=0)


https://b.l3n.co/i/4OCack.png

But curiously not in this gitlab 4035 build (https://gitlab.com/uvz/AviSynthPlus-Builds/-/blob/cadadcabe1eb31eedb1d6bee122aaf4df31f83c2/Clang/x64/AviSynth.dll):

https://c.l3n.co/i/4OJgEm.png

edit: I'm guessing it's probably the same issue hello_hello is referring to, but just in case it isn't, I'll leave this post

[pinterf]

Bug flood :)

Till then
- Planar RGB ShowBlue/Green fix
- Studio RGB to YUY2 fix (of test4)

Avisynth+ 3.7.3post test 11 (20240118 - r4059) (https://drive.google.com/uc?export=download&id=199YthQlcKrvBkBU-btd0k40Yyzvbo24K)

[pinterf]

@flossy_cake
Interesting.
The xp version (v141_xp platform) works fine. But the normal version is showing the colorful artifacts.

The same applies on the latest test11 builds.

??

[flossy_cake]

@flossy_cake
Interesting.
The xp version (v141_xp platform) works fine. But the normal version is showing the colorful artifacts.
??

What is the xp version? Windows XP?

In your gdrive builds Text() was ok in test 9 (r4022) and went bad in test 10 (r4035).

But that still doesn't explain why all the builds on gitlab are unaffected, so I'm guessing it's some kind of build issue?

[pinterf]

What is the xp version? Windows XP?

In your gdrive builds Text() was ok in test 9 (r4022) and went bad in test 10 (r4035).

But that still doesn't explain why all the builds on gitlab are unaffected, so I'm guessing it's some kind of build issue?

What makes me even more happy that the bug does not appear in debug builds. Only in release. I'm just looking at the compiled assembler code (but it's very hard to follow an optimized assembly list, as it may only loosely follow the actual program code source lines); nevertheless, I'm almost sure that it is a compiler bug; when the text bitmap is longer than 64 pixel (8 bytes) then it fails (the compiler creates more code paths, one for non-optimizable cases - this works, but for the optimized parts it switches to SIMD instructions, and I think this is where MSVC compiler produces bad code). Now I have already found the area (~100 lines of original Avisynth code) where it would generate false code.

[FranceBB]

What is the xp version? Windows XP?


Yes, the XP builds are built with MSVC set to v141_xp, /Zc:threadSafeInit and SSE2 only assembly optimizations.
They're compatible with Windows XP x86, Windows XP x64 and upwards, so they can be used in all Windows after that (Vista, 7, 8, 8.1, 10, 11) but they're gonna be slightly slower.


All the other builds (from Ferenc and Stephen, that is) are built with MSVC set to v143 and they're compatible with Windows 10 x86, Windows 10 x64 and upwards.


When you extract the package from Ferenc and Stephen, you'll always find the following folders:

- x86
- x86-xp
- x64
- x64-xp

The "xp" ones are the Windows XP and upwards ones ;)



For those wondering, Windows98SE x86 support was deprecated in 2016 after the last Avisynth 2.6.1 build, before Avisynth became Avisynth+.



ColorBars().ConvertToYV12().Trim(0, 300)
Text("Red text", font="Terminus", bold=true, size=20, text_color=$FF0000, align=5, lsp=0)
Text("\n\nGreen text", font="Terminus", bold=true, size=20, text_color=$00FF00, align=5, lsp=0)
Text("\n\n\n\nBlue text", font="Terminus", bold=true, size=20, text_color=$0000FF, align=5, lsp=0)


Avisynth 3.7.3 r4059

Windows XP:

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

Windows 10:

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



I'm just looking at the compiled assembler code

That's because you're a legend.
For me it would be like reading geoglyphs: I would be fascinated by the look of it while still not being able to understand anything it says.

What makes me even more happy that the bug does not appear in debug builds. Only in release.


Wow! So it is a compiler bug after all. O_O
I never thought I would have seen something like this in my life.
Debug is plain C/C++ so it's fine, while the XP one is up to SSE2, so I guess forcing v143 to not produce anything more than SSE2 code should "fix" the issue?

[pinterf]

It is clearly a compiler bug, I reported the issue.

https://developercommunity.visualstudio.com/t/Bad-c-codegen-in-1784-x64-unless-se/10565370?
I don't know though, where is the project source that I sent them as an attachment...

Not only finding the right place of the bug, but creating a minimal reproducible example to demonstrate the compiler error to Microsoft is very time-consuming.

I have a temporary solution for now, but I will wait for a few more days.

[qyot27]

It would have to be a very recent update, as well. I can't reproduce it here. So it could be limited to either something in VS 2022 (which I wouldn't hit because I'm still using VS 2019, and the last time I ran an update on the toolchain may have been back in July, right before building 3.7.3), or more specifically in one of the Windows toolkit update targets between the two test builds where this first arose.

https://www.mediafire.com/file/j8q93ufi7qwymqe/avisynth_build_20240119.7z/file

There seems to be a trend of weird compiler/OS bugs cropping up lately. The most recent FFMS2 C-plugin build hits memory access problems in Windows when trying to load the NovosobornayaSquare VVC sample but the exact same FFmpeg/FFMS2 commits work fine on Ubuntu.

[tormento]

Try intel compiler, it’s free in its community version.

[pinterf]

It is clearly a compiler bug, I reported the issue.

https://developercommunity.visualstudio.com/t/Bad-c-codegen-in-1784-x64-unless-se/10565370?

That was unexpectedly quick.
"Thanks for your feedback. We can reproduce the issue in VS 2022 17.8.4. And we've checked this issue has been fixed in VS2022 17.9.0 preview 3.0. ..."

[gispos]

That was unexpectedly quick.
"Thanks for your feedback. We can reproduce the issue in VS 2022 17.8.4. And we've checked this issue has been fixed in VS2022 17.9.0 preview 3.0. ..."
Sometimes life is good to you. :)

[pinterf]

RedTextBlueTextGreenTextRelease.
And a (hopefully) fixed issue found by Asd-g.
Avisynth+ 3.7.3post test 12 (20240124 - r4062) (https://drive.google.com/uc?export=download&id=1CKYoQSCHDDbMFH14j8rYNT2TI5S3aCbJ)
20240124 3.7.3 post 12
----------------------
- (temporary fix for VS2022 17.8.4 compiler bug)
- Fix #386: Interleave to call plugin destructor like StackXXXX
(20240118 3.7.3 post 11)

[FranceBB]

It works, now the v143 builds output matches the v141_xp one. :)
Thank you Ferenc, as always.

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

[VoodooFX]

Found some random bug:

https://thumbs2.imgbox.com/5f/ae/m5CMRF7K_t.png (https://images2.imgbox.com/5f/ae/m5CMRF7K_o.png)


It's generated in this "else if" block: https://github.com/Purfview/InpaintDelogo/blob/13e27f3deb83ef4415543351d362111015959e82/InpaintDelogo.avsi#L2898
There are 4 crops stacked and second from the top can be in various random colors or normal without any glitches. [with the same script]

I encountered it in 3.7.2 and 3.7.3


UPDATE:

I think I found a way how to always reproduce the bug.
Bug is when "analyze = 2" [clip there goes as yv12].
If first I use "analyze = -2" [clip there goes as rgb24] and then if I change to "analyze = 2" then it bugs out, I've no idea what happens. Some memory leak?

[pinterf]

Found some random bug:

https://thumbs2.imgbox.com/5f/ae/m5CMRF7K_t.png (https://images2.imgbox.com/5f/ae/m5CMRF7K_o.png)


It's generated in this "else if" block: https://github.com/Purfview/InpaintDelogo/blob/13e27f3deb83ef4415543351d362111015959e82/InpaintDelogo.avsi#L2898
There are 4 crops stacked and second from the top can be in various random colors or normal without any glitches. [with the same script]

I encountered it in 3.7.2 and 3.7.3


UPDATE:

I think I found a way how to always reproduce the bug.
Bug is when "analyze = 2" [clip there goes as yv12].
If first I use "analyze = -2" [clip there goes as rgb24] and then if I change to "analyze = 2" then it bugs out, I've no idea what happens. Some memory leak?
Hi,

I'd need your calling script and probably the video, the minimum you can see the garbage. All I see is that there are function(s) with a thousand parameters in that avsi. (It wanted me to Install GrunT, O.K., I copied the dll. Then now it requires a mask string definition. Given the fact I don't use it for myself, I need help.

[VoodooFX]

Hi,

I'd need your calling script and probably the video, the minimum you can see the garbage. All I see is that there are function(s) with a thousand parameters in that avsi. (It wanted me to Install GrunT, O.K., I copied the dll. Then now it requires a mask string definition. Given the fact I don't use it for myself, I need help.

Here you go: https://we.tl/t-BD8RzJnv38

Run it as is, then run it with "Analyze=2" and you should see error from the script that it didn't found suitable frames (if it bugs out).
[then if it bugs out you can remove padding in extension from the "txt" file and use "Show=7" so you can see video with the bugged frames]

EDIT:

I think these should be enough to run it:
AvsInpaint v1.3 or later ( https://github.com/pinterf/AvsInpaint ).
MaskTools2 ( https://github.com/pinterf/masktools ).
RgTools ( https://github.com/pinterf/RgTools ).
GRunT ( https://github.com/pinterf/GRunT ).
RT_Stats ( http://avisynth.nl/index.php/RT_Stats ).
FrameSel ( http://avisynth.nl/index.php/FrameSel ).
LSMASH ( http://avisynth.nl/index.php/LSMASHSource ).

EDIT2:
On Windows 7 x64, but I run AvS x86 with x86 plugins in AvsPmod v2.7.4.5

EDIT3:
Just reproduced it with your shared "b12" test files.
Btw, rar'ed txt file is wrongly named, should be named as "xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt" if you'll want to see bugged video.

[gispos]

Question for the Avisynth developers or those who can answer it.

When I get audio samples with 'get_audio', the time required depends on the video filters used. Which makes me wonder!
I assumed that this is not the case, is this another C Interface bug or is there no other way?

Because it is almost impossible to create an audio buffer of several frames without major delays in the image playback.

Is there another way to get the audio samples without processing all the video filters?

Would it make sense to derive an extra audio clip with 'KillVideo' from the clip or would this audio clip then claim its parent when getting an audio sample from another frame?

#######################

Each line represents 10 video frames from which the audio samples were read in a loop with get_audio from each video frame
So before reading and timing 'get_frame' was called and then only 'get_audio' was executed.
Time in seconds:

with video filters and with prefetch(4) (get audio fluctuates strongly, 0.5 is too much)
0.598999977112 !!!
0.00300002098083
0.00200009346008
0.00200009346008
0.588999986649 !!!
0.00200009346008
0.0019998550415
0.00200009346008
0.588999986649 !!!
0.00300002098083
0.00200009346008
0.000999927520752
0.609999895096 !!!
0.000999927520752
0.0019998550415
0.000999927520752
0.600000143051 !!!

with video filters without prefetch (get audio is mostly slow)
0.204999923706
0.203000068665
0.207000017166
0.000999927520752
0.210000038147
0.209000110626
0.0019998550415
0.209999799728
0.210000038147
0.232999801636
0.000999927520752
0.209000110626
0.204999923706
0.206000089645
0.211999893188
0.209000110626

without video filters and without prefetch (get audio is very fast)
I would have expected that even with video filtering
0.000999927520752
0.000999927520752
0.000999927520752
0.00100016593933
0.0
0.000999927520752
0.000999927520752
0.000999927520752
0.0
0.0019998550415
0.000999927520752
0.00100016593933
0.0
0.000999927520752
0.000999927520752
0.000999927520752
0.0

without video filters but with prefetch(4) (get audio is fast)
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.00100016593933
0.00100016593933
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752

[Emulgator]

Would it make sense to derive an extra audio clip with 'KillVideo' from the clip or would this audio clip then claim its parent when getting an audio sample from another frame?
Remembering script snippets from the past I am feeling that being the solution, but lets see what more experienced coders have to say.

[pinterf]

Here you go: https://we.tl/t-BD8RzJnv38

Run it as is, then run it with "Analyze=2" and you should see error from the script that it didn't found suitable frames (if it bugs out).
[then if it bugs out you can remove padding in extension from the "txt" file and use "Show=7" so you can see video with the bugged frames]

EDIT:

I think these should be enough to run it:
AvsInpaint v1.3 or later ( https://github.com/pinterf/AvsInpaint ).
MaskTools2 ( https://github.com/pinterf/masktools ).
RgTools ( https://github.com/pinterf/RgTools ).
GRunT ( https://github.com/pinterf/GRunT ).
RT_Stats ( http://avisynth.nl/index.php/RT_Stats ).
FrameSel ( http://avisynth.nl/index.php/FrameSel ).
LSMASH ( http://avisynth.nl/index.php/LSMASHSource ).

EDIT2:
On Windows 7 x64, but I run AvS x86 with x86 plugins in AvsPmod v2.7.4.5

EDIT3:
Just reproduced it with your shared "b12" test files.
Btw, rar'ed txt file is wrongly named, should be named as "xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt" if you'll want to see bugged video.

Hi, thanks, downloaded, run and now I don't know what to see.

You wrote that I should rename the text file xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-255.txt_to_disable_this_file to xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt.
But the script would generate files with "A-2" in their name (instead of "A2"). As I didn't see any changes (or dont' know what to look for), I'd rather stop experimenting with renaming, I don't see the logic behind them. Anyway I tried both.

The first mp4 file is different as well, than it is required in the script. I renamed it.

I can see however colorful blocks in the top third of xxx2.bmp_InpaintDelogo3_296-136-296-136_A-2-30_Deep1.ebmp
Is this the bug?

What does it mean "you should see error from the script that it didn't found suitable frames"? I have to watch the frames or there will be an error message or some generated files will contain the error message?

[pinterf]

Question for the Avisynth developers or those who can answer it.

When I get audio samples with 'get_audio', the time required depends on the video filters used. Which makes me wonder!
I assumed that this is not the case, is this another C Interface bug or is there no other way?


I have some tips (without knowing the reason).

Does it happen if source video is ColorBars?

If not, then I'd suspect the "real" source filter, which would seek and decode the video and audio in a way which is not 100% independent.

During video processing and Prefetch, out-of-order frame requests must be served by the source. I've seen already that a 1-2-3-4-5...98-100-99-... frame reqest pattern would kill the speed of the source filter, because the 100->99 change would cause re-read and re-decode the whole 0-100 frame range.

The audio requests are pass-through operations when video filters do nothing with them.

Then I'd test the slowdown and speed fluctuations with a test script, which is using different audio and video sources, and finish the script with "AudioDub".

[tormento]

During video processing and Prefetch, out-of-order frame requests must be served by the source. I've seen already that a 1-2-3-4-5...98-100-99-... frame reqest pattern would kill the speed of the source filter, because the 100->99 change would cause re-read and re-decode the whole 0-100 frame range.
Idea from a programming noob: why not to let the user have 2 independent buffers (with customizable frame numbers, not necessarily the same number for both), one for the forward requests and the other one for the backward ones?

How does motion vector filters deals with frame calls? Perhaps a dual buffer strategy would give some nice numbers and solve other issues.

It’s a long time that I am thinking about the bad results when denoising the frames close to the end of scene change. In my mind a reverse order denoising would function and having a dual buffer could help.

[VoodooFX]

The first mp4 file is different as well, than it is required in the script. I renamed it.

Oh, I shared the wrong video, here are the right test files -> https://we.tl/t-B8xrryRIfT

I don't know what to see.
To see the error from an assert in the script [in the red letters], if there is no error then there is no bug,
To be sure, check generated "xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt" file, if it says "# Total frames to analyze: 2000" then definitely no bug.

You wrote that I should rename the text
That's only after the bug is encountered, it's not important, forget that...

But the script would generate files with "A-2" in their name (instead of "A2")

ebmp & txt files with "A-2" are created only with "Analyze=-2".
There is no bug with "Analyze=-2", we run it to trigger the bug in a next run with "Analyze=2".
Note: Generated files with "Analyze=-2" are not relevant for "Analyze=2" run.

To trigger the bug:
1) Run with "Analyze=-2"
2) After "1" finished, run "Analyze=2" - here we should see error from Assert if bug is present.


Rinse And Repeat:
a) Close AvsPmod.
b) Delete all ebmp & txt files.
c) Do "1" & "2" steps again.

[VoodooFX]

Other people could test it too, so we can pin point the bug faster.

My test environment: On Windows 7 x64, Avisynth+ 3.7.3 (3.7.2 tested too), I run AvS x86 with x86 plugins in AvsPmod v2.7.4.5

[pinterf]

Other people could test it too, so we can pin point the bug faster.

My test environment: On Windows 7 x64, Avisynth+ 3.7.3 (3.7.2 tested too), I run AvS x86 with x86 plugins in AvsPmod v2.7.4.5
I now have the red Assert saying to change the threshold.
And I have only one txt file after the first pass (-2):
xxx2.bmp_InpaintDelogo3_296-136-296-136_A-2-30_Deep1.txt
with content
# Total frames to analyze: 2000
0,-2000

The 2nd pass would generate the other txt, which would be this one: xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt

But I don't have such file because of the assert?

How did you visualize the stacked clip? (where there is the stange clip - the second one from the top?)

[VoodooFX]

I now have the red Assert saying to change the threshold.

That means you successfully reproduced the bug.


The 2nd pass would generate the other txt, which would be this one: xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt
But I don't have such file because of the assert?

Yes.

How did you visualize the stacked clip? (where there is the stange clip - the second one from the top?)

When you got the assert:
1) Just rename txt file from "Analyze=-2" to "xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt".
2) In the script change to "Show=7"
3) Press or trigger refresh in AvsPmod. -> You should see the bugged clip.

NOTE:
If no bug then in txt file should be written frames numbers/ranges with minmax lower than 15 in chroma & lower than 30 in Y. Because of the bug there are no frames written there.

[pinterf]

That was a nasty bug. I’d rate it 9 out of 10 on the disgusting factor. It gave me an adrenaline rush but made me mentally empty for the rest of the week.

The bug had impact between sessions. When a program loaded Avisynth.DLL once, then run and reload scripts, e.g. AvsPMod editor. "The first takes everything", whatever script was using TurnLeft for RGB all the later TurnLefts were trying to save the results into RGB planes, even if they were of YUV format. Which of course was resulting in garbage.

Thanks for the challenge.

Avisynth+ 3.7.3post test 14 (20240131 - r4066) (https://drive.google.com/uc?export=download&id=1nrdoQgzzYJh7RwkkrPZwW9OGpmI53A9-)
20240131 3.7.3 r4066
---------------------
- Fix corrupt Turn functions when a planar RGB turn would be followed by a YUV Turn.
Regression since TurnXXXX supports planar RGB (2016.08.23; probably since r2081 commit dba954e2de0c9c6218d17fc5c4974f4c28b627c3)
See VooDooFX's AvsInPaint problem at https://forum.doom9.org/showthread.php?p=1996653#post1996653

EDIT: pls test, and if it's good enough, then I'm gonna commit the fix to the central git repo

[VoodooFX]

That was a nasty bug. I’d rate it 9 out of 10 on the disgusting factor. It gave me an adrenaline rush but made me mentally empty for the rest of the week.

The bug had impact between sessions. When a program loaded Avisynth.DLL once, then run and reload scripts, e.g. AvsPMod editor. "The first takes everything", whatever script was using TurnLeft for RGB all the later TurnLefts were trying to save the results into RGB planes, even if they were of YUV format. Which of course was resulting in garbage.

Thanks for the challenge.

You're welcome.
"test14" - works good, no bug.


Btw, I was hopping that the bug will be related to the two bugs I encountered when I was creating gradients in Y8, mentioned there:
https://forum.doom9.org/showthread.php?p=1987019#post1987019


Second bug there aka "Another for official avs" - I couldn't remember how to reproduce it, script was somewhat similar to the first bug, I only remember the effect of it, instead of completely broken gradient (the bottom stacked clip in the example) it had a slight smudge of grey at the bottom of a clip.

[pinterf]

You're welcome.
"test14" - works good, no bug.

It’s no surprise that it worked, since I deliberately skipped test13. :)

[jpsdr]

3.7.3...??? Shouldn't be 3.7.4 ?

[VoodooFX]

3.7.3...??? Shouldn't be 3.7.4 ?

"3.7.3post" means post 3.7.3 aka 3.7.4.

[rgr]

During conversion ("ffmpeg -i input.avs output.mp4"), it rarely happens that suddenly the conversion simply stops (no error occurs, the line in ffmpeg simply stops refreshing).

I'm rather sure it's a problem with AviSynth, probably with some filter (I use ffms2, QTGMC, ff3dfilter and lsfmod + a few others like Vinverse).

How can I diagnose what is causing it?

[FranceBB]

it rarely happens that suddenly the conversion simply stops

I'm pretty sure it's the "frozen as ice" issue with avstp.dll I faced a long time ago and that Ferenc fixed.

See here: https://github.com/pinterf/mvtools/issues/46

Either update to the new avstp.dll https://github.com/pinterf/AVSTP/releases or get rid of the one you have in the plugins folder.
I'm pretty sure that it will solve the issue ;)

[real.finder]

speaking of cuda did someone note this https://github.com/vosen/ZLUDA ? did nekopanda Neo plugins work with it?

it was work with intel gpu https://github.com/vosen/ZLUDA/tree/60d2124a16a7a2a1a6be3707247afe82892a4163 but now it only work with amd gpu

[tormento]

speaking of cuda did someone note this
Nvidia stated a few days ago that reverse engineering of CUDA is illegal and I don’t see a very bright future for that project.

[hello_hello]

I'm not sure if it's ColorBars or the conversion to YUV, but there appears to be an out of range black. I assume it shouldn't be out of range after the conversion, although as ColorBars outputs limited range RGB, maybe there's supposed to be an out of range black. I don't know, so I thought I'd ask.
Cheers.

The first Image is
ColorBars().ConvertToYV24() with the histogram on top.
The second image is just to show where it is.
ColorBars().ConvertToYV24().Levels(0,2.5,255,0,255,coring=false)
Both color bars are half size.

https://i.ibb.co/5hVTLd5/A.jpg

https://i.ibb.co/zPNPqHP/B.jpg

[Emulgator]

ColorBars called without any parameters will export RGB32 8bpc PLUGE 7,16,25, and IIRC there is no "limited range RGB", so I would expect this.

[hello_hello]

Good to know. Thanks.

[DTL]

ColorBars()

Outputs narrow RGB. So White is 235 and Black is 16 as expected in lower stripe for levels check/setup. Also RGB data of 75% amplitude for WYCGRBB colour bars are in 180/16 narrow range.

(180-16)/(235-16) = 0.74885

Also
ColorBars()
PropShow()

correctly displays internal metadata marking:
_ColorRange = 1 = limited
_Matrix = 0 = rgb

[wonkey_monkey]

I may have found a bug with PlanarRGB (32-bit float, at least, I haven't tried any other depths yet). I use this code to re-use the src frame as dst, if it's writeable, or to create a new dst frame (I'm going to overwrite the contents anyway, so I do this to avoid the unnecessary copy that MakeWriteable might do):

PVideoFrame src = child->GetFrame(n, env);
PVideoFrame dst = src->IsWritable() ? src : env->NewVideoFrameP(vi, &src);


The result of this code:

int planes[3] = { PLANAR_R, PLANAR_G, PLANAR_B };

for (int p = 0; p < 3; ++p) {
debug("%p , %p", dst->GetReadPtr(planes[p]), dst->GetWritePtr(planes[p]));
}


is always similar to the following:

00000000116E0A40 , 00000000116E0A40
0000000010C94040 , 0000000000000000
00000000111BA540 , 00000000111BA540


In other words, dst->GetReadPtr(PLANAR_G) returns a valid pointer, but dst->GetWritePtr(PLANAR_G) returns null.

Presumably something to do with this in interface.cpp:

BYTE* VideoFrame::GetWritePtr(int plane) const {
if (!plane || plane == PLANAR_Y || plane == PLANAR_G) { // planar RGB order GBR
if (vfb->GetRefcount()>1) {
_ASSERT(FALSE);
// throw AvisynthError("Internal Error - refcount was more than one!");
}
return (refcount == 1 && vfb->refcount == 1) ? vfb->GetWritePtr() + GetOffset(plane) : 0;
}
return vfb->data + GetOffset(plane);
}

[DTL]

It looks was same issue as in DecodeYUVtoRGB - I sometime got bad pointers if using PLANAR_R G B defines. I report it to pinterf but there were no detailed check what happen. So I simply use hand-adjusted numbers to get planes pointers -
https://github.com/DTL2020/ConvertYUVtoRGB/blob/625dcbfb91a2c11bc7850e8261b6bfc4b5a14519/DecodeYV12toRGB.cpp#L551

auto dstp_R = dst->GetWritePtr(4);
auto dstp_G = dst->GetWritePtr(6);
auto dstp_B = dst->GetWritePtr(2);

auto dstp_BGRA = dst->GetWritePtr(2);
auto dst_pitch_BGRA = dst->GetPitch();

auto dst_pitch_R = dst->GetPitch(PLANAR_R);
auto dst_pitch_G = dst->GetPitch(PLANAR_G);
auto dst_pitch_B = dst->GetPitch(PLANAR_B);

Though GetPitch() with PLANAR_R G B defines is working OK.

Maybe something is wierd with include headers or some other defines required or other C++ magic.

In the current AVS+ repository https://github.com/AviSynth/AviSynthPlus/blob/85057371294405f745f5c51b7a39fa0e3fdde821/avs_core/include/avisynth.h#L163
enum AvsPlane {
DEFAULT_PLANE = 0,
PLANAR_Y = 1 << 0,
PLANAR_U = 1 << 1,
PLANAR_V = 1 << 2,
PLANAR_ALIGNED = 1 << 3,
PLANAR_Y_ALIGNED = PLANAR_Y | PLANAR_ALIGNED,
PLANAR_U_ALIGNED = PLANAR_U | PLANAR_ALIGNED,
PLANAR_V_ALIGNED = PLANAR_V | PLANAR_ALIGNED,
PLANAR_A = 1 << 4,
PLANAR_R = 1 << 5,
PLANAR_G = 1 << 6,
PLANAR_B = 1 << 7,
PLANAR_A_ALIGNED = PLANAR_A | PLANAR_ALIGNED,
PLANAR_R_ALIGNED = PLANAR_R | PLANAR_ALIGNED,
PLANAR_G_ALIGNED = PLANAR_G | PLANAR_ALIGNED,
PLANAR_B_ALIGNED = PLANAR_B | PLANAR_ALIGNED,
};

So PLANAR_R = 1 << 5,
PLANAR_G = 1 << 6,
PLANAR_B = 1 << 7, is much larger than 2,4,6 but may not work at some use cases as expected with GetWritePtr() calls (from some C++ objects ?) ?

From your part of program text:
something to do with this in interface.cpp:
return (refcount == 1 && vfb->refcount == 1) ? vfb->GetWritePtr() + GetOffset(plane) : 0;

If PLANAR_G processed as it should - there are 2 more ways to fail to zero -
refcount == 1 (not 1)
or
vfb->refcount == 1 (not 1)

So maybe you need to prepare somehow 'dst' pointer (around that 'refcount' C++ magic) before calling GetWritePtr() and system will return finally valid G-plane pointer as vfb->GetWritePtr() + GetOffset(plane) ? Can you build debug build of AVS+ and go with debugger inside GetWritePtr() function to check what is happen with (refcount == 1 && vfb->refcount == 1) ? condition and which of 2 (or both ?) internal 'refcount' variables cause condition to fail ? Or it is really vfb->GetWritePtr() returns zero ptr (and GetOffset(plane) returns zero because G is the first plane in planar RGB as comment notes) ?

Though other interesting question is: If 'dst' object is not in the 'right condition' to call GetWritePtr() method - why R and B planes are not fail call (returning failed zero ptr) ?

[StvG]

I may have found a bug with PlanarRGB (32-bit float, at least, I haven't tried any other depths yet). I use this code to re-use the src frame as dst, if it's writeable, or to create a new dst frame (I'm going to overwrite the contents anyway, so I do this to avoid the unnecessary copy that MakeWriteable might do):

PVideoFrame src = child->GetFrame(n, env);
PVideoFrame dst = src->IsWritable() ? src : env->NewVideoFrameP(vi, &src);


IsWritable() - "The rule about writability is this: A buffer is writable if and only if there is exactly one PVideoFrame pointing to it." (from here (http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API)). If src->IsWritable() return true you do PVideoFrame dst = src and dst is not anymore writable because you have two PVideoFrame pointing to child->GetFrame(n, env).

[DTL]

So dst must be pointer first and either point to existing src or create new object with env->NewVideoFrameP(vi, &src) ?

Something like

PVideoFrame *dst;
if (src->IsWritable()
dst = &src;
else
dst = &(env->NewVideoFrameP(vi, &src));

?

[wonkey_monkey]

dst = &(env->NewVideoFrameP(vi, &src));

That seems unsafe. Wouldn't there then be zero real references to the newly-created video frame, because there's no PVideoFrame variable? Maybe:


PVideoFrame dst;
PVideoFrame *dst_p;
if (src->IsWritable() {
dst_p = &src;
} else {
dst = env->NewVideoFrameP(vi, &src);
dst_p = &src;
}

(*dst_p)->GetWritePtr(...



is safer?

I assume there is some logic to the code in interface.cpp which only does the reference count checks for PLANAR_Y and PLANAR_G, but I don't know what it might be. Unless that's the real bug, that it fails to check on the other planes? And should it throw an exception instead of returning null?

[StvG]

So dst must be pointer first and either point to existing src or create new object with env->NewVideoFrameP(vi, &src) ?

Something like

PVideoFrame *dst;
if (src->IsWritable()
dst = &src;
else
dst = &(env->NewVideoFrameP(vi, &src));

?

Just:


PVideoFrame dst;
if (!src->IsWritable())
dst=env->NewVideoFrameP();

uint8_t* dstp = (dst) ? dst->GetWritePtr() : src->GetWritePtr;

Edit: Or another way:


if (!src->IsWritable())
env->MakeWriteable(&src);

uint8_t* dstp = src->GetWritePtr;