AviSynth+ thread Vol.2

[flossy_cake]

Originally Posted by StainlessS

http://avisynth.nl/index.php/Interna...FunctionExists

Thanks - and sorry for not seeing it in avisynth.nl wiki - at the time I was using the offline documentation html files that come with Avisynth which is out of date and doesn't mention those ones like VarExist and FunctionExists.

[gispos]

Originally Posted by DTL

New version - https://github.com/DTL2020/ConvertYU...ases/tag/0.3.0

Now can take also 10..16bits YUV planar and convert to 8bit YV12 internally before processing.

With skipping ConvertBits(8) before YUV to RGB with one more full frame scan it also adds performance at out-of-cache frame sizes. If AVS can either have lots of ready to use SIMD functions inside for different conversions with single source scan or can dynamically compile required SIMD program for requested format conversion it can save from several host RAM read/writes for sequence of formats conversion and adds to performance.

That's great, the new version runs faster even with YUV420P16 than the previous one with only YUV420P8.
With the previous one I had to put a ConvertBits(8) in front.

Thanks for the new version!
A big improvement would be if the mod 64 could be scaled down.

I have a new Pre-Release that works with both DLL versions.
https://drive.google.com/drive/folde...usp=share_link

[DTL]

Here is attempt to process all widths - https://github.com/DTL2020/ConvertYU...ases/tag/0.3.1

It looks with 64 samples per pass it is not compatible with max mod64 bytes rows strides ? So the last columns up to 63 are processed with simple C-scalar program. At UHD frame 3840+60 width and at i3-9100T CPU it looks not add significant penalty -
3840 width 313 fps
3840+60 width 308 fps.

It is not tested with all possible frame widths so some bugs may happen.

"the new version runs faster even with YUV420P16 than the previous one with only YUV420P8. "

From ver 0.3.0 I set cs default to false as I see it typically make storing data faster and users may be lazy to test best setting of true/false at current host.

[gispos]

Originally Posted by DTL

Here is attempt to process all widths - https://github.com/DTL2020/ConvertYU...ases/tag/0.3.1
.

Wow! Wow! Wow! I can hardly believe it, excellently done!

Tried all dimensions and no error received so far.
4K ColorBar YUV420P10 with AvsPmod 'Resample Filter' and option 'Prefetch display conversion' resized to 1980 x 1080
runs in playback with ~153 fps shrunk to 1280 x 720 it is ~189 fps

ColorBar 1920 x 1080 YUV420P10 ~196 fps in the playback with display drawing.

I've spent a few hours optimizing everything, at least it was worth it.

Thanks!

[flossy_cake]

Originally Posted by StainlessS

And see Gavino stuff here [try move as much code as you can out of Scriptclip script and into function].

Unfortunately it appears the solution above requires ScriptClip(local=true) which doesn't allow messaging between frames, which I absolutely need.

So I am stuck with a huge memory leak - around 2MB/sec in my case

Is there perhaps some way to manually "clear the string heap"?

[StainlessS]

Is there perhaps some way to manually "clear the string heap"?

Nope, nuttin' at all, no mem is garbage collectable.

What are you trying to do, post what you attempted.

EDIT: You can still use globals even when Local = true.
Must use eg

Global SomeVar = WhateverVar

Trying to pass a 'Stored Frame", will fail after a few (hundred or thousand) frames, ie Huge mem usage.
(You are calcing current frame, based on previous frame, which is also based on frame before it, etc.
Not possible to just "throw away" prev temp frames as re-seek requires every frame before it to be available.)

EDIT:
I have tried many times (and find hard to accept the futility) to try find solution for what it is I think that you are trying to do,
even this attempt at solution failed.
FrameStore v0.03 - Avs+ x86/x64 - 15 Jan 2019
https://forum.doom9.org/showthread.php?t=175212

[flossy_cake]

Originally Posted by StainlessS

What are you trying to do, post what you attempted.

This is leaking around 1.3MB/sec for 30fps video on my system (too big to paste on forum): https://pastebin.com/raw/pKfBJ26Q

This however produces no leak: https://pastebin.com/raw/PGWtzubz

But it won't allow runtime funcs like this:

ScriptClip( last,
\ function [] (c) {
	
	diff = YDifferenceToNext(c, -1)  # requires local=true, else error message
	c
	
} , after_frame=true, local=false)

If I set local=true then I lose the ability to message between frames:

global PrevFrameNumber = 0

ScriptClip( last,
\ function [] (c) {
	
	global PrevFrameNumber = PrevFrameNumber + 1  # doesn't work, just stays at 1
	c.SubTitle(String(PrevFrameNumber))  
	
} , after_frame=true, local=true)

Perhaps messaging could be done through frame properties instead.

[StainlessS]

Sorry, I aint got a clue about that new fangled "Function [] (c)" stuff, old dog and new trick thingy.

Perhaps messaging could be done through frame properties instead.

Same, old dog, new tricks.

[StainlessS]

Is this what you are tryin' to do with that there new fangled stuff ?

/*
ScriptClip( last,
\ function [] (c) {
    # EDIT: "Plane Difference: this filter can only be used within run-time filters.
    diff = YDifferenceToNext(c, -1)  # requires local=true, else error message
    c

} , after_frame=true, local=false)
*/

Colorbars.Killaudio.ConvertToYV12

Function func(clip c) {
    diff = YDifferenceToNext(c, -1)  # EDIT: Works. Does NOT require local=true
    c.Subtitle(String(diff))
}

SSS = """
    func()
"""

ScriptClip( SSS , after_frame=true, local=false)

And

/*
ScriptClip( last, function [] (c) {
    global PrevFrameNumber = PrevFrameNumber + 1  # doesn't work, just stays at 1
    c.SubTitle(String(PrevFrameNumber))
} , after_frame=true, local=true)
*/


Colorbars.Killaudio.ConvertToYV12

Global PrevFrameNumber = 0

Function func(clip c) {
    Global PrevFrameNumber = PrevFrameNumber + 1  # EDIT: Works,  Does NOT stay at 1
    c.SubTitle(String(PrevFrameNumber))
}

SSS = """
    func()
"""

ScriptClip( SSS , after_frame=true, local=true)

EDIT: Both above WORK OK.

[Rob105]

path = "C:\Video\"

v0 = FFmpegSource(path + "video.mp4")

v1 = ImageSource(path + "Colors Gradient Horizontal 1920x1080.jpg", fps=50, end = 299).crop(0,980,0,0)
v2 = ImageSource(path + "BW Gradient Horizontal 1920x1080.jpg",     fps=50, end = 299).crop(0,980,0,0)

StackVertical(v0, v1, v2)

Avisynth open failure: StackVertical: image formats don't match

How do i make it work?

Source files https://www.upload.ee/files/15277223/video.zip.html

[flossy_cake]

Originally Posted by StainlessS

EDIT: Both above WORK OK.

Hmm neither are working for me - I'm getting the same result as the previous samples. I copy pasted your exact code so I'm not sure what's going on. What version Avisynth are you using? I've got 3.7.3 (r3936, 3.7, x86_64).

[FranceBB]

Originally Posted by Rob105

How do i make it work?

Easy peasy lemon squeezy: a simple Converttoyv12() after you index the images will do it.

FFMPEGSource2("D:\video\video.mp4", fpsnum=50000, fpsden=1000, atrack=-1)

img1=ImageSource("D:\video\Colors Gradient Horizontal 1920x1080.jpg", fps=50, end=212).crop(0, 980, 0, 0).Converttoyv12()

img2=ImageSource("D:\video\BW Gradient Horizontal 1920x1080.jpg", fps=50, end=212).crop(0, 980, 0, 0).Converttoyv12()


StackVertical(last, img1, img2)

Explanation:

when you stack together different clips, they must all be the same, so you need to convert either the original video file you're indexing to reflect the two jpg you're trying to add on OR the other way around. In the example, I've done the opposite, so I've converted the two images to yv12 (4:2:0 planar 8bit).


I can now shut down my computer and go to bed :P

[StainlessS]

Originally Posted by flossy_cake

Hmm neither are working for me - I'm getting the same result as the previous samples. I copy pasted your exact code so I'm not sure what's going on. What version Avisynth are you using? I've got 3.7.3 (r3936, 3.7, x86_64).

v3.7.3(r3825,master, x86_64)

EDIT: Re-checked and both do work OK here.
Perhaps others with either version could verify results.

[flossy_cake]

Originally Posted by StainlessS

v3.7.3(r3825,master, x86_64)

EDIT: Re-checked and both do work OK here.
Perhaps others with either version could verify results.

Thanks, I tried a few other versions without luck. In the end I got it working by copying exactly what Gavino's SRestore does:

global count = 0

ScriptClip(last, "MyFunc(last, current_frame)", after_frame=true, local=false)

function MyFunc(clip c, int current_frame) {
    
	global count = count + 1	
	diff = YDifferenceToNext(c, -1)
	c.SubTitle(string(diff) + ", " + string(count))
}

Passing current_frame to MyFunc is what makes it work for me, otherwise I get "this filter can only be used within run-time filters".

Hopefully there is no other weird side effect of doing it this way, but I've got a feeling it's going to be weird about something.

[StainlessS]

Also, the first of the scripts [works for me, not for you], kinda surprised me,
I was under the impression that current_frame did not survive when calling a function,
stangely it worked for me in that script where I might have expected it not to.
[perhaps something strange in the version I'm currently using].

Passing current_frame to MyFunc is what makes it work for me, otherwise I get "this filter can only be used within run-time filters".

Yep, I posted similar in Usage a little while ago.
https://forum.doom9.org/showthread.p...42#post1986042

Originally Posted by StainlessS

Current_frame is not available outside of the runtime environment, and dont make much sense there either.
But, (probably not of use in required case) you can hack a one time use (on a single frame) just by setting
it to that frame number, eg

blankclip(length=100,pixel_type="YV12")
C = Last.BlankClip(length=0) # zero len clip, same characteristics as Last clip
For(n=0,FrameCount-1) {
    current_frame = n # HACK for below AverageLuma
    Y = AverageLuma # access frame n
    T = Trim(n,-1)
    T = T.Subtitle(String(n) + String(Y," : %f"),align=5)
    C = C ++ T  # add single frame n, to clip so far
}

C # Play C

current_frame is set only for use within runtime (eg by ScriptClip) where it is initialised before each frame that is processed by
the script arg of Scriptclip. Hacking current_frame to some number just allows to use some runtime func (eg AverageLuma), on that SINGLE frame.

EDIT:
Nuther script of limited use

blankclip(length=100,pixel_type="YV12")

Function SomeFunc(clip c, int n) { # Dont think current_frame is visible within this func, but can be provided by caller in n
    current_frame = n
    Y = c.AverageLuma
    Return Y
}

SSS="""
    Y = SomeFunc(Last,current_frame)
    return Subtitle(String(current_frame) + String(Y," : %f"))
"""

ScriptClip(SSS)

# ...

EDIT:

Function SomeFunc(clip c, int current_frame)

Does not taste quite right to me, so I used an int n then assigned to current_frame internal to function.

[Gavino]

Originally Posted by StainlessS

Also, the first of the scripts [works for me, not for you], kinda surprised me,
I was under the impression that current_frame did not survive when calling a function,
stangely it worked for me in that script where I might have expected it not to.
[perhaps something strange in the version I'm currently using].

Are you using GRunT's ScriptClip()?
In GRunT (unlike vanilla Avisynth 2.x), current_frame is a global variable (though still of course only visible inside the run-time environment).
Avs+ has incorporated some functions of GRunT, but I'm not sure if this one applies there.

[StainlessS]

Are you using GRunT's ScriptClip()?

Yep, renaming Grunt.dll so as not to use it,

1st script produces error report.

2nd script, shows subtitle '1' for all frames.

Cheers Gavin. [nice Welsh name].

[DTL]

Made new version of converter to RGB32 - https://github.com/DTL2020/ConvertYU...ases/tag/0.4.0

It is finally more correct processing in 16bit intermediates and in narrow range the resudual error only about +1LSB. After gained to Full range - at some colours may reach error of 2LSB.

Also when compared to ConvertToRGB32(matrix="PC.709") it was found that matrix (coefficients ?) in AVS core is somehow broken:

At script:

ColorBarsHD(640, 480, pixel_type="YV24")
ConvertToYV12()

ConvertToRGB32(chromaresample="point", matrix="PC.709")

Output for colours (R,G,B):
Yellow 181, 180, 12
Cyan 12, 181, 180
Green 13, 181, 12
Magenta 183, 15, 184
Red 184, 15, 16
Blue 15, 16, 184

The DecodeYUVtoRGB with narrow range mapping (gain=64 and offset=16) keep output in 15..17 and 179..181 range. It was found with math simulation the 8bit YUV can not be decoded to ideal 16 and 180 RGB at all colours because or already rounding errors in 8bit YUV. So only with 10bit and more it can be reach ideal 16 and 180 levels output.

Also added 32bit immediates processing mode - it run 2+ times slower at AVX2 and provide only slightly better precision in the Full range mapping (error looks like +-1LSB). And close to no better in narrow range. So it looks 32bit immediate processing only required for >8bit sources and results. And can make a bit better precision with 8bit output only if input is >8bit.

For some possible future of fastest 16bit immediate processing engine for YV12 to RGB32 it is possible to play with coefficients tweaking and rounders tweaking and may be reduce average error over all possible range of YUV input 8bit values - using some math simulator engine. But it require programmer of such optimizing engine.

Also added x86_32 build if someone still use 32bit Windows. It runs only slightly slower (register file size in 32bit CPU mode is 1/2 of size and compiler make more data temporal store/load from cache).

[kedautinh12]

First time for 32 bit from DTL

[poisondeathray]

Note that "PC matrices" are not quite the same thing as "Studio RGB", or "limited range RGB" used in broadcast or some NLE's

The equivalent way in avisynth as what's used a Studio RGB NLE (like vegas) for 8bit for that example above would be

ColorBarsHD(640, 480, pixel_type="YV24")
ConvertToYV12()
Levels(0,1,255,16,235, coring=false)
ConvertToRGB32(chromaresample="point", matrix="rec709")

Y 180,179,16
C 16,181,179
G 16,179,14
M 179,16,181
R 180,16,17
B 15,16,180

There was an old dedicated "studio RGB" function by "trevlac" for avisynth


EDIT:
It should be coring=false . Limiting (for example 0,255) is separate . Nominal Black to white is defined as 16 to 235 for studio RGB, but you can have superblack, superwhite . If you clip it in the levels (coring=true), you never get superblack or superwhite