AviSynth+ thread Vol.2

[flossy_cake]

It is usually assumed that an A/V difference of 100 ms or even more is not perceptible.

In MPC-HC I can adjust audio delay with hotkeys in 10ms increments and at 100ms it's noticeable to me the lip sync is off.

[pinterf]

Heh - small fix for UV scale at RGB<->YUV at 'limited/narrow' levels mapping https://forum.doom9.org/showthread.php?p=1988318#post1988318 is not included in the 3.7.3 release. Pinterf promised to make a big redesign of all 'convert' core functions with a fix for this issue included (also with better performance) but it looks like it will happen in some 3.7.4testXXX next builds. So currently with 3.7.3 release the same workaround with additional UV scaling is required.
Yeah, promised, it's still here on my desktop, but did not make a final-final test, so the release did not get untested change. Probably I'm going to upload the changes as is to the git repo, because I didn't find issues by myself.

[pinterf]

this make dither tools not working

colorbars(pixel_type="yv12")
Dither_convert_8_to_16()
ditherpost(mode=-1)

https://i.postimg.cc/4yZLWYbZ/Untitled.png (https://postimages.org/)

edit: anything newer than Avisynth+ 3.7.3 test 7 (20230223) will give same error
Is it still an issue the 3.7.3 release? I'm unable to reproduce it

I've raised an issue here in order to check it later: https://github.com/AviSynth/AviSynthPlus/issues/365 now it's "later", but I'm unable to see the error. I don't understand, becasue my code does contain a check against such plugins built with pre-V5 AVISYNTH_INTERFACE_VERSION.
Maybe an Avisynth 2.5 plugin was accidentally built with AVISYNTH_INTERFACE_VERSION = 5 in its avisynth.h????)

If you still get the error, please upload me somewhere the exact plugin binary you are using, thanks.

[FranceBB]

Is it still an issue the 3.7.3 release?

No, looks like it was broken in some of the 3.7.3 test but eventually got fixed in the stable build:

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


Sorry for not closing this https://github.com/AviSynth/AviSynthPlus/issues/365 I should have checked too, but I very rarely have time to do anything nowadays... :(

I'm gonna comment it there too, thank you as always, Ferenc, the conditional to check the version of the plugins and apply the workaround is indeed working as expected ;)

Yeah, promised, it's still here on my desktop, but did not make a final-final test, so the release did not get untested change.

Don't worry, I think plenty of people here are gonna be more than happy to test it on the field as soon as the first 3.7.4 test1 release is gonna be available (me included). Testing is literally the least we could do ;)

[StvG]

Is it still an issue the 3.7.3 release? I'm unable to reproduce it

I've raised an issue here in order to check it later: https://github.com/AviSynth/AviSynthPlus/issues/365 now it's "later", but I'm unable to see the error. I don't understand, becasue my code does contain a check against such plugins built with pre-V5 AVISYNTH_INTERFACE_VERSION.
Maybe an Avisynth 2.5 plugin was accidentally built with AVISYNTH_INTERFACE_VERSION = 5 in its avisynth.h????)

If you still get the error, please upload me somewhere the exact plugin binary you are using, thanks.

It's still an issue with 3.7.3 release. I reproduced it with this version (http://ldesoras.free.fr/src/avs/dither-1.28.1.zip) (the version from here (http://avisynth.nl/index.php/Dither)).
What version did you use?

[FranceBB]

It's still an issue with 3.7.3 release. I reproduced it with this version (http://ldesoras.free.fr/src/avs/dither-1.28.1.zip) (the version from here (http://avisynth.nl/index.php/Dither)).
What version did you use?

Just to keep everyone aligned, the conversation is continuing here: https://github.com/AviSynth/AviSynthPlus/issues/365

I used v1.28.0 built on Wednesday 07 October 2020, 16.27.15 however even if I swap dither.dll 1.28.0 from October 2020 with the one you provided (which is the same as the one provided by Real Finder) that was built on Monday 17 July 2023, 08.33.18, I get the same result:

https://user-images.githubusercontent.com/18946343/275250175-9839e62b-95e4-4346-8d23-fa0ecebefb84.png

VersionString: AviSynth+ 3.7.3 (r4003, 3.7, x86_64)
VersionNumber: 2.60
File / Product version: 3.7.3.0 / 3.7.3.0
Interface Version: 10
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SYSTEM32\avisynth.dll
Avisynth.dll time stamp: 2023-07-15, 21:48:08 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+

[C 2.5 Plugins (64 Bit)] [Version, Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64+\assrender.dll [0.35.0.0, 2021-03-04]
C:\Program Files (x86)\AviSynth+\plugins64+\mlrt_ncnn.dll [1.0.1.0, 2023-03-20]
C:\Program Files (x86)\AviSynth+\plugins64+\mlrt_ov.dll [1.0.0.0, 2023-03-20]

[C++ 2.5 Plugins (64 Bit)] [Version, Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64+\dither.dll [n/a, 2023-07-17]
C:\Program Files (x86)\AviSynth+\plugins64+\HDRMatrix-x64.dll [n/a, 2018-01-09]
C:\Program Files (x86)\AviSynth+\plugins64+\HDRNoise-x64.dll [n/a, 2018-01-09]
C:\Program Files (x86)\AviSynth+\plugins64+\HDRSharp-x64.dll [n/a, 2018-01-09]
C:\Program Files (x86)\AviSynth+\plugins64+\LeakKernelDeint.dll [1.5.4.0, 2010-03-14]
C:\Program Files (x86)\AviSynth+\plugins64+\VSFilter.dll [3.0.0.306, 2014-12-07]
C:\Program Files (x86)\AviSynth+\plugins64+\warpsharp.dll [n/a, 2011-06-14]

Play audio is of course enabled in AVSPmod mod.


Ferenc also tried to reproduce it, but to no avail... :(
The fact that you can also reproduce this, StvG, and not just real.finder, means that there's something really there.
In the meantime, despite not being able to reproduce the issue (just like I can't reproduce it on my pc :( ), Ferenc made some changes and provided a test build https://drive.google.com/uc?export=download&id=1xHP6jaFDpAb4j4pXKoVe2L6rw2qEohs4
Testing on my computer would be pointless 'cause I can't reproduce the error anyway, so can you guys who can actually reproduce the error, test the new build and see if it solves it?

[StvG]

@FranceBB, thanks for the info.

From that github thread, it seems they found the culprit.

[FranceBB]

From that github thread, it seems they found the culprit.

Yes, Ferenc made a new build that solves the issue.
In case anyone needs it, you can find the latest Ferenc build here: Link (https://drive.google.com/uc?export=download&id=1auyCcQRg1QJbSc6RL1Rq53ApJ7KTVzxN)

[pinterf]

Yes, Ferenc made a new build that solves the issue.
In case anyone needs it, you can find the latest Ferenc build here: Link (https://drive.google.com/uc?export=download&id=1auyCcQRg1QJbSc6RL1Rq53ApJ7KTVzxN)
yes, but do not use it yet for production please, contains some unfinished code parts on other areas. Wait a little bit for the official git commits.

[pinterf]

Try this one. Much safer, git commits are still not uploaded, I'd wait a bit.
Avisynth 3.7.3+ tests
Avisynth+ 3.7.3post test 4 (20231019 - r4013) (https://drive.google.com/uc?export=download&id=1xQ9EmT2LG5Ouqz-Je7rvDTP01Sc4Ve5i)

20231019 3.7.3 post 4
---------------------
- Fix #365 (https://github.com/AviSynth/AviSynthPlus/issues/365)
Avisynth 2.5 plugins when NICE_FILTER would crash with "invalid response to CACHE_GETCHILD_AUDIO_MODE".
Bug appeared since reintroducing audio cache in 3.7.3.
- Fix #370: array size assert error in ConvertToYUY2 when internally ConvertTo422 is called.
Reason: ConvertToYUV422 has one more parameter (ChromaOutPlacement) than ConvertToYUY2 has
- Issues mentioned in #354 https://github.com/AviSynth/AviSynthPlus/issues/354
- Leave _ColorRange frame property as-is, when using matrix names "PC.709" or "PC.601",
for example in ConvertToRGB32.
Formerly _ColorRange property would always set to 0 (full range), even if a limited range
clip (e.g. ColorBarsHD) was inputted. Now we act as the specification
( http://avisynth.nl/index.php/Convert ) says:
"PC.601 and PC.709 keep the range unchanged, instead of converting between 0-255 RGB
and 16-235 YUV, as is the normal practice."
Now ColorBarsHD().ConvertToRGB32(matrix="PC.601").propShow()
would display "_ColorRange=1 (limited)", since ColorbarsHD's output is limited as well.
- 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)

[FranceBB]

Try this one. Much safer, git commits are still not uploaded, I'd wait a bit.
Avisynth 3.7.3+ tests
Avisynth+ 3.7.3post test 4 (20231019 - r4013) (https://drive.google.com/uc?export=download&id=1xQ9EmT2LG5Ouqz-Je7rvDTP01Sc4Ve5i)


- 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)

Uhhhhh, as someone who's forced to work with Studio RGB (Narrow Range) all the time this is very much appreciated! :D

[pinterf]

Uhhhhh, as someone who's forced to work with Studio RGB (Narrow Range) all the time this is very much appreciated! :D
This one was quite a huge change throughout the code, this is why I haven't uploaded the source it to github yet. Pls. report if old things would get broken or something is not clear or illogical.

[FranceBB]

Well, I was testing exactly that and I noticed another issue. :(
Unfortunately, PlanarTools (http://avisynth.nl/index.php/PlanarTools) produce an Access Violation both with 3.7.3 stable and with this new build.


FFImageSource("Image.png")

ExtractPlane(0)


https://i.imgur.com/2Zc69XI.png

The image is a simple RGB32 (so RGB24 + 8 for the alpha channel) png lossless, but it can be replaced with a simple ColorBars():


ColorBars(848, 480, pixel_type="RGB32")

ExtractPlane(0)


https://i.imgur.com/2Zc69XI.png

This was tested on Windows 10 22H2 x64 Enterprise, but I also tested it on Windows XP x86 Professional and the result is also an error but perhaps even worse:

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

[pinterf]

Well, I was testing exactly that and I noticed another issue. :(
Unfortunately, PlanarTools (http://avisynth.nl/index.php/PlanarTools) produce an Access Violation both with 3.7.3 stable and with this new build.


FFImageSource("Image.png")

ExtractPlane(0)


https://i.imgur.com/2Zc69XI.png

The image is a simple RGB32 (so RGB24 + 8 for the alpha channel) png lossless, but it can be replaced with a simple ColorBars():


ColorBars(848, 480, pixel_type="RGB32")

ExtractPlane(0)


https://i.imgur.com/2Zc69XI.png

This was tested on Windows 10 22H2 x64 Enterprise, but I also tested it on Windows XP x86 Professional and the result is also an error but perhaps even worse:

https://i.imgur.com/Nsamsd0.png
The latest source code does not have a binary release.

But this PlanarTools is crashing of course. It is using the IScriptEnvironment2 interface which is not allowed and Avisynth version dependant.

in Avisynth.h:
/* -----------------------------------------------------------------------------
Note to plugin authors: The interface in IScriptEnvironment2 is
preliminary / under construction / only for testing / non-final etc.!
As long as you see this note here, IScriptEnvironment2 might still change,
in which case your plugin WILL break. This also means that you are welcome
to test it and give your feedback about any ideas, improvements, or issues
you might have.
----------------------------------------------------------------------------- */



As I can see, this issue is already fixed in the github source and is using the usual SetCacheHints method instead of calling the crashing SetFilterMTMode. So a rebuild would help.

[FranceBB]

Gotcha!
Well, I used this as a temporary workaround:

FFImageSource("image.png")

my_alpha=ShowAlpha(pixel_type="RGB24")


RemoveAlphaPlane()

ConvertBits(16)
ConvertToPlanarRGB(matrix="PC.709", interlaced=false)

Cube("3a_BT709_HLG_Type1.cube", interp=1, fullrange=1)

my_HLG=last

ConvertBits(my_alpha, 16)
ConvertToPlanarRGB(matrix="PC.709", interlaced=false)

Cube("3a_BT709_HLG_Type1.cube", interp=1, fullrange=1)

ConverttoY(matrix="PC.2020")


my_alpha_HLG=last


AddAlphaPlane(my_HLG, my_alpha_HLG)


There I was working in Full Range with your new build and it was fine as levels were preserved during the conversion given that I used "PC.2020".
About RGB Narrow Range, this is an RGB 16bit Limited TV Range (i.e Narrow Range) in PQ:


Frame: 831
Keys: 15
MasteringDisplayMaxLuminance (4000.0)
MasteringDisplayMinLuminance (0.005)
MasteringDisplayPrimariesX (0.68, 0.265, 0.15)
MasteringDisplayPrimariesY (0.32, 0.69, 0.06)
MasteringDisplayWhitePointX (0.3127)
MasteringDisplayWhitePointY (0.329)
_AbsoluteTime (34.659625)
_ColorRange (1[limited])
_DurationDen (24000)
_DurationNum (1001)
_FieldBased (0[progressive])
_Matrix (0[RGB])
_PictType (I)
_SARDen (1)
_SARNum (0)


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


it's correctly recognized as limited tv range RGB.
Now, in 3.7.3 stable, if I did something like:


#Indexing Studio RGB PQ
LWLibavVideoSource("Test.mxf")

ConverttoYUV444(matrix="Rec2020")

then levels would have been screwed 'cause everything would have been shrinked 'cause it basically was gonna do the limited of the limited tv range as it automatically assumed that RGB was Full Range, in fact:

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

which is clearly wrong.
Now, as per your new build, I expected it to read the Limited TV Range flag and actually get it right automagically, however I seem to be misunderstanding something 'cause this:

#Indexing Studio RGB PQ
LWLibavVideoSource("Test.mxf")

ConverttoYUV444()

results in the same (wrong) level shift as it does the limited of the limited again:

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

I even tried to force the range detection with:

PropSet("_ColorRange", 1)

just to be 100% sure, but nothing...

This is the build:

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

[real.finder]

The latest source code does not have a binary release.

But this PlanarTools is crashing of course. It is using the IScriptEnvironment2 interface which is not allowed and Avisynth version dependant.

in Avisynth.h:
/* -----------------------------------------------------------------------------
Note to plugin authors: The interface in IScriptEnvironment2 is
preliminary / under construction / only for testing / non-final etc.!
As long as you see this note here, IScriptEnvironment2 might still change,
in which case your plugin WILL break. This also means that you are welcome
to test it and give your feedback about any ideas, improvements, or issues
you might have.
----------------------------------------------------------------------------- */



As I can see, this issue is already fixed in the github source and is using the usual SetCacheHints method instead of calling the crashing SetFilterMTMode. So a rebuild would help.

back then https://forum.doom9.org/showpost.php?p=1915428&postcount=473 it seems not worth it for avs+

ExtractPlane(0) can't be replaced with avs+ Extract()? like ExtractR()

[pinterf]

FranceBB, thanks for the feedback, I'm looking into that.
edit: my bad, I've propably used cut-and-paste at one place instead of copy-paste, so before RGB->444 conversion no properties were obtained from 0th frame. Expect new builds on Friday.
edit2: Thursday is the new Friday. :)
Avisynth+ 3.7.3post test 5 (20231026 - r4017) (https://drive.google.com/uc?export=download&id=1gFcu3Wp3jRiT7lAi7WzrV3Rym7y9jcPO)
(with narrow rgb -> 444 fix - hopefully)

[pinterf]

Avisynth+ 3.7.3post test 6b (20231031 - r4018) (https://drive.google.com/uc?export=download&id=1ONJtxKUXh4L-eQi3j7_RoSbVJUdvfg3f)

Change from test5:
- Fix #368 (https://github.com/AviSynth/AviSynthPlus/issues/368)
Make proper vertical alignment for multiline text (containing "\n" and parameter "lsp" is defined)
in Subtitle and Text when vertical alignment is set to bottom (align=1,2,3) or center (4,5,6).
Ending "\n" is treated as a new empty line, so "Line1" is one line, but "Line1\n" has two lines and the
second one is an empty line.
See also https://forum.doom9.org/showthread.php?t=185145

edit: zip content fixed.

[Emulgator]

Jó estet Ferenc !
Here my findings from 17.03.2023 as I was puzzled too by AviSynth's typographic habits
while getting my portalscope tidied. Maybe it helps while rewriting documentation...
(Don't know the english wording for some typographical expressions, so please be kind and translate on your side.)

AviSynth Subtitle align

789
456
123

size (total line size) := 1/8 Unterlänge + 3/4 Capital letter size + 1/8 Akzent-Oberlänge

7 y:=Oberlänge, Text hängt unter seiner Akzent-Oberlänge y und ist linksbündig, läuft ab x nach rechts
8 y:=Oberlänge, Text hängt unter seiner Akzent-Oberlänge y und ist x-zentriert, läuft nach links und rechts
9 y:=Oberlänge, Text hängt unter seiner Akzent-Oberlänge y und ist rechtsbündig, läuft ab x nach links

4 y:=Grundlinie, Text steht auf seiner Grundlinie y und ist linksbündig, läuft ab x nach rechts
5 y:=Grundlinie, Text steht auf seiner Grundlinie y und ist x-zentriert, läuft nach links und rechts
6 y:=Grundlinie, Text steht auf seiner Grundlinie y und ist rechtsbündig, läuft ab x nach links

1 y:=Unterlänge, Text schwebt auf seiner Unterlänge y und ist linksbündig, läuft ab x nach rechts
2 y:=Unterlänge, Text schwebt auf seiner Unterlänge y und ist x-zentriert, läuft nach links und rechts
3 y:=Unterlänge, Text schwebt auf seiner Unterlänge y und ist rechtsbündig, läuft ab x nach links

Vertical centering:

7,8,9 y:=y-size/2
4,5,6 y:=y+size*3/8
1,2,3 y:=y+size/2

subtitle applies font_angle first, then aligns along the original orientation.

In the end AviSynth's derivation appears logical:
For a fullsize glyph having all possible underlengths/upperlengths/accents
giving one of the 4 width x height corner coordinates
any appropriate (inward running) alignment's rendering must result
in touching, but not exceeding both appropriate screen borders.

P.S. As this has been discussed recently,
I would concur that this had been conceived with only one-liners in mind,
so one should not expect any provisions for multiline-text.

[Rob105]

Vertical centering:

7,8,9 y:=y-size/2
4,5,6 y:=y+size*3/8
1,2,3 y:=y+size/2

Can you provide a working code or explain how i can adopt it to my code i am getting errors like I don't know what 'y' means.

[Reel.Deel]

Can you provide a working code or explain how i can adopt it to my code i am getting errors like I don't know what 'y' means.

Y is the height of the frame:

Colorbars()
y2 = (last.Height() + 18) / 2 # assume font size is 18
Subtitle("asdfg", y=y2)

[StainlessS]

Avisynth+ 3.7.3post test 6 (20231031 - r4018)

Change from test5:
- Fix #368 (https://github.com/AviSynth/AviSynthPlus/issues/368)
Make proper vertical alignment for multiline text (containing "\n" and parameter "lsp" is defined)
in Subtitle and Text when vertical alignment is set to bottom (align=1,2,3) or center (4,5,6).
Ending "\n" is treated as a new empty line, so "Line1" is one line, but "Line1\n" has two lines and the
second one is an empty line.
See also https://forum.doom9.org/showthread.php?t=185145

"Ending "\n" is treated as a new empty line, so "Line1" is one line, but "Line1\n" has two lines and the second one is an empty line."

Nope, dont like that, but dont like below either :(
"Line1" has only a single line of text.
"Line1\n", has still only a single line of text, text written/flushed to output device, and logical print cursor position moves down 1 line due to NewLine '\n',
but there is no more text to print and so still only a single line of text was output.
"Line1\nLine2", 2 lines output, "Line1" and "Line2", with a Newline moving cursor down between them.
"Line1\nLine2\n", 2 lines output, "Line1" and "Line2", with a Newlines moving cursor down after both of them.
A final move of the cursor (after final print line) does not affect the number of lines printed.
[EDIT: This Line in SubV script function,
# Line count with/without final newline
means that we want only the text lines count, and it has to be the same whether or not the multiline string ends with a newline or not.
END EDIT]


However, NewLines in any position other than at very end of the string, have to be counted as they affect the 'area' of [and position of any additional] print.
"\nLine2", is 2 lines. In this case leading empty line has to be taken into account. The initial '\n' prints empty line and then moves down 1 line and prints "Line2".
"\nLine2\n". is 2 lines, the initial '\n' prints empty line and then moves down 1 line and prints "Line2", the final '\n' only moves the cursor, does not affect 'area' of print.
"Line1\n\n". is 2 lines, the initial '\n' prints empty line and then moves down 1 which does affect print 'area', the final '\n' only moves the cursor, does NOT affect 'area' of print.
"\nLine2\n\n", is 3 lines, If an ending empty line is required (to affect justification) then cannot omit the final '\n' (ie "\nLine2\n" is only 2 lines, not 3).

"\nLine2\nLine3\n", is 3 lines. [final '\n' just moves cursor]
"\nLine2\nLine3\n\n", is 4 lines. [final '\n' just moves cursor]
"\n\nLine3\nLine4", is 4 lines.
"\n\nLine3\nLine4\n", is 4 lines. [final '\n' just moves cursor]
"\n\nLine3\nLine4\n\n", is 5 lines. [final '\n' just moves cursor]
"\n\nLine3\n\nLine5", is 5 lines.
"\n\nLine3\n\nLine5\n", is 5 lines. [final '\n' just moves cursor]
"\n\nLine3\n\nLine5\n\n", is 6 lines. [final '\n' just moves cursor]

Ending complete multi-line string with '\n' has no justifiication effect [same line count as the string without any trailing '\n'].
Ending complete multi-line string with '\n\n' vertical center justifies upwards by 0.5 lines [vertical print lines 'area' seems 1 bigger than actual text lines].
Ending complete multi-line string with '\n\n\n' vertical center justifies upwards by 1 line [vertical print lines 'area' seems 2 bigger than actual text lines].
Ending complete multi-line string with '\n\n\n\n' vertical center justifies upwards by 1.5 lines [vertical print lines 'area' seems 3 bigger than actual text lines].
Ending complete multi-line string with '\n\n\n\n\n' vertical center justifies upwards by 2.0 lines [vertical print lines 'area' seems 4 bigger than actual text lines].

Similarly, starting a multiline string with '\n' will vertical center justify downwards by 0.5 of a line (and '\n\n' by 1, and '\n\n\n' by 1.5).

Its a bit awkward to explain, but has to work like above so as to be able to affect vertical justification using Newlines.
To be sure that you are counting your newlines correctly, always end with '\n'.

[B]Counting Lines in Multi-line string:
For vertical justification we need to count the number of lines printed in a multi-line string.
So, firstly if the multi-line text string is "" then number of lines is 0, Otherwise below,
To count the text lines, you need to count the '\n' newlines, but, if newline '\n' does not occur at very end of the multi-line string, then counting
newlines alone gives wrong answer (you need add 1 to line count in such a case).

[kedautinh12]

@pinterf, the x64 folder of your download link is test 5 cause it's compiler at 27/10 while x64-xp, x86, x86-xp are test 6 cause it's compiler at 31/10

[pinterf]

Thanks, x86 folder contained an x64 dll as well, package is fixed, please redownload (the link was edited above)
@Emulgator, thank you
@StainlessS Thanks for the feedback, I'm going to digest your whole post later, I see now that newline count must be changed (following "Counting Lines in Multi-line string").
Till then, pls test it with this future change in mind. I'd really like to upload my changes to git before I die :) (I was lightly and gently hit by a car yesterday when riding home - fortunately I have no injuries)

[kedautinh12]

Hope someone inherit you before you die or avs+ will die so long before someone development it :D

[FranceBB]

(I was lightly and gently hit by a car yesterday when riding home - fortunately I have no injuries)

:scared:

OH!
I'm so sorry to hear that, Ferenc! :(
Get well soon and rest.

[wonkey_monkey]

Just came across an oddity. Since 2.54, ChangeFPS has a parameter linear = true which forces linear access (apparenly for up to 10 frame gaps).

If you use SelectEven (or some other frame-culling filter) after ChangeFPS with linear = true (the default), it will insist on fetching every frame, which can cause quite an unexpected slowdown.

Does anyone know the rationale for linear = true?

[StainlessS]

P,
This is source for RT_TxtQueryLines(), however it counts '\n' [Chr(10) Linefeed, rather than "\n" subtitle string style escape].
Some scriptors {MAC users ?} use Chr(13) {carriage return} instead of correct [IMHO] Chr(10) {LineFeed} for NewLine, we have to deal
with both in RT_TxtQueryLines(), but you do not have to do that for subtitle escaped strings.
We also do not know source of the provided string, and so have to cope with matched pairs of both '\r' + '\n' OR, '\n' + '\r'
just incase somebody got the order mixed up. DOS order should be CR/LF where paired {if you create a text file containing
lots of wrongly paired LF/CR, and load it into eg Word, it will drive the poor app crazy... very jumpy about-y}.
Use if you wish., should be easy modded.

Anyways, you be careful and stop having fights with the traffic, bicycle riders rarely win such fights.
This guy here was NEARLY lightly and gently hit by a car yesterday too [standing by his broken down car on motorway].
https://www.thesun.co.uk/motors/24589027/watch-shocking-moment-driver-smashes-into-stationary-lamborghini/

OOps, forgot the source.

AVSValue __cdecl RT_TxtQueryLines(AVSValue args, void* user_data, IScriptEnvironment* env) {
const char *Str=args[0].AsString();
const char *s=Str;
int c,Lines=0;
while(c=*s) {
if(c=='\n' || c == '\r') {
if((c=='\n' && s[1]=='\r') || (c=='\r' && s[1]=='\n'))
++s;
++Lines;
}
++s;
}
if(Str < s && s[-1] != '\n' && s[-1] != '\r')
++Lines; // Last line not n/l terminated, but still counts
return Lines;
}

[FranceBB]

Just came across an oddity. ChangeFPS has a parameter linear = true which forces linear access (apparenly for up to 10 frame gaps).

If you use SelectEven (or some other frame-culling filter) after ChangeFPS with linear = true (the default), it will insist on fetching every frame, which can cause quite an unexpected slowdown.

Does anyone know the rationale for linear = true?

I'd like to know it too, also 'cause it actually caused some errors in my scripts.
Essentially, if the difference between the ChangeFPS() target frame rate and the original clip framerate was higher than x it outputted an error and I've seen it in lots of logs as I was using it in one of my automated workflows.
I changed it to linear=false in the script, the files processed fine and I never looked back, but I'd like to know more on what exactly that parameter is doing.
Still, I think that linear=false will reproduce the original behavior, especially 'cause before that you could use ChangeFPS() on literally any FPS in input to produce any FPS in output by dropping or duplicating frames (the only one having limitations was ConvertFPS() instead as it uses blending).

This can be easily reproduced with:

Old Avisynth (works):

ColorBars(848, 480, pixel_type="YV12")

ChangeFPS(100)

ChangeFPS(5)

Avisynth 3.7.3 r4013 (doesn't work):

ColorBars(848, 480, pixel_type="YV12")

ChangeFPS(100)

ChangeFPS(5)

https://i.imgur.com/3NUlLQs.png

Avisynth 3.7.3 r4013 works (old behavior is restored with linear=false):

ColorBars(848, 480, pixel_type="YV12")

ChangeFPS(100, linear=false)

ChangeFPS(5, linear=false)


Wouldn't it make more sense to have linear=false set by default rather than having it set to true by default so that the old behavior is restored?

[tormento]

I'd really like to upload my changes to git before I die :)
I forbid you to die at least until you will introduce CUDA processing and filtering ;)

[Selur]

I forbid you to die at least until you will introduce CUDA processing and filtering
+ port a working removedirt to Vapoursynth :D
(using just specific mods (https://forum.doom9.org/showthread.php?t=185121) does kind of work, but is just a workaround)
;)

[DTL]

mvtools 2+ requires additional 10..20+ years of development too.

[pinterf]

P,
This is source for RT_TxtQueryLines(), however it counts '\n' [Chr(10) Linefeed, rather than "\n" subtitle string style escape].

Thanks, it's already a comment/uncomment in the code, anyway in SubTitle and Text the string "\n" is valid only if it's not inside a "\\n" sequence (which would print the \n string itself).

[pinterf]

@Selur, probably I'm too old for learning new things such as porting filters to VS, nor have I pressure such as impatient customers who'd like to see that feature ported :)
And despite my two younger sons are just finishing their IT studies at the technical university, I cannot pass my knowledge, because they know nothing about Avisynth and video filter programming and have other interests.

[ryrynz]

I nominate DTL and Tormento.

[StainlessS]

SubTitle and Text the string "\n" is valid only if it's not inside a "\\n" sequence (which would print the \n string itself).
Not sure if I was never aware or if forgot about the '\\n' escape of newline in Subtitle.

But on Wiki, it does say that it is so, as here,
int lsp =
Line Spacing Parameter; enables multi-line text (where "\n" enters a line break). If lsp is less than zero, inter-line spacing is decreased; if greater, the spacing is increased, relative to Windows' default spacing. By default, multi-line text disabled.
In the unlikely event that you want to output the characters "\n" literally in a multi-line text, you can do this by using "\\n".

And like the others, we hopes that U live forever [what a ghastly thought].

[pinterf]

Avisynth+ 3.7.3post test 8 (20231103 - r4021) (https://drive.google.com/uc?export=download&id=1ZGt6F7pLnMj6lo_n-gwjl4S6PtOYHD35)
20231103 3.7.3 post 8
---------------------
- New: "Info" new parameter
bool "cpu" (true)
If set to false, displaying CPU capabilities is disabled
- Enhancement: "Info" displays partially visible lines as well.
- Address #366 partially
"Info" new parameters, similar to SubTitle/Text:
int "align" (default 7: top left)
float "x" (default 4 for top left, screen center or right otherwise)
float "y" (default 0 for top left, screen center or bottom otherwise)
See https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/info.html
- Fix #368 (https://github.com/AviSynth/AviSynthPlus/issues/368)
Make proper vertical alignment for multiline text (containing "\n" and parameter "lsp" is defined)
in Subtitle and Text when vertical alignment is set to bottom (align=1,2,3) or center (4,5,6).
See also https://forum.doom9.org/showthread.php?t=185145
Note 1: The "\n" after the last line does not result in an empty bottom line, so both "Line1" and "Line1\n" are one-line texts.
- Fix: "Text" use "lsp" parameter the same way as in SubTitle: in 1/8 pixel units, not in 1 pixels.
Historically "lsp" in SubTitle is measured in 1/8 pixels, so "lsp"=8 means 1 pixels.
"lsp" Line Spacing Parameter sets the additional line space between two lines in 1/8 pixel units.
- Fix: "Text" vertical alignment position would be wrong for multiline strings containing even number of lines.

[pinterf]

test8->test9: propShow user experience enhancement. Unreal Engine 5.3 nanite support... eeerrr not :) Simply you can change color and position of the text.
Avisynth+ 3.7.3post test 9 (20231105 - r4022) (https://drive.google.com/uc?export=download&id=1ZsU6x-ttYJxUugYAAw_4eTSe5bpc4F2L)
20231105 3.7.3 post 9
---------------------
- (#366):
"propShow" add further parameters, like in "Text".
string "font", int "text_color", int "halo_color", bool "bold", float "x", float "y", int "align"

full signature: c[size]i[showtype]b[font]s[text_color]i[halo_color]i[bold]b[x]f[y]f[align]i

font default: "Terminus" (can also be: "info_h")
bold default: false
x, y default: depending on the "align"
align default: 7 (top left) valid values 1-9 (see your numeric keyboard)
halo color MSB = FF (e.g. FF000000) -> no outline + semi transparent background
FE (e.g. FE000000) -> outline + semi transparent background
01 (e.g. 01000000) -> no outline + normal display
00 (e.g. 00000000) -> outline + normal display

propShow(align=1, halo_color=$FF000000)
propShow(size=6,bold=true, align=3, halo_color=$FE000000)
propShow(size=16,bold=true, align=5, halo_color=$00000000)
propShow(font="info_h", align=9, halo_color=$01000000)
See https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/propShow.html
- New: "Info" new parameter
bool "cpu" (true)
If set to false, displaying CPU capabilities is disabled
- Enhancement: "Info" displays partially visible lines as well.
- (#366)
"Info" new parameters, similar to SubTitle/Text:
int "align" (default 7: top left)
float "x" (default 4 for top left, screen center or right otherwise)
float "y" (default 0 for top left, screen center or bottom otherwise)
See https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/info.html
- Fix #368 (https://github.com/AviSynth/AviSynthPlus/issues/368)
Make proper vertical alignment for multiline text (containing "\n" and parameter "lsp" is defined)
in Subtitle and Text when vertical alignment is set to bottom (align=1,2,3) or center (4,5,6).
See also https://forum.doom9.org/showthread.php?t=185145
Note 1: The "\n" after the last line does not result in an empty bottom line, so both "Line1" and "Line1\n" are one-line texts.
- Fix: "Text" use "lsp" parameter the same way as in SubTitle: in 1/8 pixel units, not in 1 pixels.
Historically "lsp" in SubTitle is measured in 1/8 pixels, so "lsp"=8 means 1 pixels.
- Fix: "Text" vertical alignment position would be wrong for multiline strings containing even number of lines.
- Fix #365 (https://github.com/AviSynth/AviSynthPlus/issues/365)
Avisynth 2.5 plugins when NICE_FILTER would crash with "invalid response to CACHE_GETCHILD_AUDIO_MODE".
Bug appeared since reintroducing audio cache in 3.7.3.
- Fix #370: array size assert error in ConvertToYUY2 when internally ConvertTo422 is called.
Reason: ConvertToYUV422 has one more parameter (ChromaOutPlacement) than ConvertToYUY2 has
- Issues mentioned in #354 https://github.com/AviSynth/AviSynthPlus/issues/354
- Leave _ColorRange frame property as-is, when using matrix names "PC.709" or "PC.601",
for example in ConvertToRGB32.
Formerly _ColorRange property would always set to 0 (full range), even if a limited range
clip (e.g. ColorBarsHD) was inputted. Now we act as the specification
( http://avisynth.nl/index.php/Convert ) says:
"PC.601 and PC.709 keep the range unchanged, instead of converting between 0-255 RGB
and 16-235 YUV, as is the normal practice."
Now ColorBarsHD().ConvertToRGB32(matrix="PC.601").propShow()
would display "_ColorRange=1 (limited)", since ColorbarsHD's output is limited as well.
- Studio RGB (limited) range will now be recognized (through _ColorRange=1) and utilized in
conversions from RGB, such as in GreyScale, ConvertToY, ConvertToYUVxxx (latter fixed in test5).
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)

[kedautinh12]

Avs+ r4029
https://gitlab.com/uvz/AviSynthPlus-Builds

[flossy_cake]

Hello, I am trying to workaround some undesired interpreter behaviour...

clip1 = myFunc(setting=1)
clip2 = myFunc(setting=2)
if (something==true){ clip2 }
else { clip1 }

It seems no matter which way the conditional evaluates, the interpreter always initialises myFunc() twice at lines 1 and 2. I can tell it's doing this because globals are getting initialised twice inside myFunc() and this is not allowing me to manage multiple calls to myFunc().

I can workaround it by going...

if (something==true){ myFunc(settting=2) }
else { myFunc(setting=1) }

But then I can't use variables to reference clips which is a bit of a downer.

Is there any way to tell Avisynth interpreter to only initialise function calls if they are going to be used at runtime? (during "get frame" or whatever it's called)?

:thanks:

[FranceBB]

Hi guys,
I know that there are lots of things going on for the upcoming version of Avisynth and this is probably gonna be one of the least important things so it can really be at the very bottom of the list, but I'm just gonna write it down here 'cause otherwise I fear we might forget: is anyone gonna add UTF-8 support to DirectShowSource()?

The reason why I'm asking is that this whole thing originated from this discussion here in the AVSPmod mod topic (post 1554) (https://forum.doom9.org/showthread.php?t=175823&page=78) in which we were trying to organize a list on which encoding schemes are supported by the various indexers and we just realized that DirectShowSource() is working with ANSI / Enhanced ANSI (like WinLatin) but it's lacking UTF-8 support.

I'm posting it here only 'cause DirectShowSource() is one of the plugins distributed by default as part of the main Avisynth+ installation so it's almost as if it's part of the core, let's say, and let's be honest, it's also 'cause I had no idea where else to ask xD

[pinterf]

Definitely, this is the right place. :). I have started to think there was nothing left to do.

[tormento]

definitely, this is the right place. :). I have started to think there was nothing left to do.


cuda….

[gispos]

cuda cuda cuda cuda... :D

[pinterf]

is anyone gonna add UTF-8 support to DirectShowSource()?
Here you are:
Avisynth+ 3.7.3post test 10 (20231202 - r4035) (https://drive.google.com/uc?export=download&id=1yuiF6rnphnfpBoZGFTsT9vKPGiZxbGCX)
It works the usual way, add utf8=true.

[Emulgator]

DG land would love to work with pinterf on this. Other stakeholders should participate as well.
The main effort would be to agree an architecture/API for minimizing CPU<->GPU transfers.
And then when that is in place to enhance internal and 3rd-party filters to support that.
DG demonstrated gains of 300%+ for typical scripts using his CUDASynth framework, but nobody seemed interested.
Maybe Vulkan is a better way to go to avoid nVidia fixation. We need to look into all this.
Yeees ! Thanks, Donald and Ferenc, for all the work !

[FranceBB]

Here you are:
Avisynth+ 3.7.3post test 10 (20231202 - r4035) (https://drive.google.com/uc?export=download&id=1yuiF6rnphnfpBoZGFTsT9vKPGiZxbGCX)
It works the usual way, add utf8=true.

Works like a charm.
Reliable as ever, Grandmaster Ferenc! :D

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

This year, under the Christmas tree, Santa Ferenc brought us presents:

https://i.imgur.com/6b5ZTfb.png

[pinterf]

Thank you for your kind and unusually visual feedback :)

[lewyturn]

After I upgraded to version 3.7.3, "GetChannel" does not work, there is only image but no sound. After I returned to version 3.7.2, the sound returned. Please tell me what I missed.

-----------------------------------------------------------------------------
SetWorkingDir("c:\AviSynth+\plugins64+")


v1 = FFmpegSource2("D:\video\v1.mp4",atrack=-2).TurnRight()
v2 = FFmpegSource2("D:\video\v2.mp4",atrack=-2).TurnRight()
a1=DirectShowSource("D:\video\v1.mp4")
a2=DirectShowSource("D:\video\v2.mp4")


b=BlankClip(length=5307,width=2160,height=1920,fps=29,channels=2,color=$000000)
xpos = 1080
ypos = 0
k=Overlay(b,v1)

video=Overlay(k,v2,x=xpos,y=ypos)

mono1=GetLeftChannel(a1, 1).AmplifydB(7)
mono2=GetChannel(a2, 2).AmplifydB(2)

audio=mergechannels(mono1,mono2)

AudioDub(video,audio)

[StainlessS]

Add Return a1.Info after line a1=DirectShowSource("D:\video\v1.mp4")
to check for audio.

EDIT: Is this correct ? [error for me]

mono1=GetLeftChannel(a1, 1).AmplifydB(7)
mono2=GetChannel(a2, 2).AmplifydB(2)


EDIT: GetLeftChannel() does not take a channel number.

After I returned to version 3.7.2, the sound returned.
Dont see how that is possible with that same error script.