AviSynth+ thread Vol.2

[FranceBB]

Originally Posted by 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)

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

[pinterf]

Originally Posted by FranceBB

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

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 produce an Access Violation both with 3.7.3 stable and with this new build.

FFImageSource("Image.png")

ExtractPlane(0)

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)

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:

[pinterf]

Originally Posted by FranceBB

Well, I was testing exactly that and I noticed another issue.
Unfortunately, PlanarTools produce an Access Violation both with 3.7.3 stable and with this new build.

FFImageSource("Image.png")

ExtractPlane(0)

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)

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:

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)





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:



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:



I even tried to force the range detection with:

PropSet("_ColorRange", 1)

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

This is the build:

[real.finder]

Originally Posted by pinterf

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...&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)
(with narrow rgb -> 444 fix - hopefully)

[pinterf]

Avisynth+ 3.7.3post test 6b (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

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]

Originally Posted by Emulgator

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]

Originally Posted by Rob105

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]

Originally Posted by pinterf

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'. [but if you dont, there is an implied one there anyway]

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

[FranceBB]

Originally Posted by pinterf

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

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/2458...y-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]

Originally Posted by wonkey_monkey

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)

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]

Originally Posted by pinterf

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