AviSynth+ thread Vol.2

[pinterf]

Dear all, download
Avisynth+ v3.6.1 test build 5 (20200603)
Addressing mp_pipeline and further CPP 2.5 compatibility fixes (GRunT CPP 2.5 runtime filters, AverageLuma, etc.)
New: Histogram("Levels"): add greyscale support

[Groucho2004]

Originally Posted by pinterf

Dear all, download
Avisynth+ v3.6.1 test build 5 (20200603)
Addressing mp_pipeline and further CPP 2.5 compatibility fixes (GRunT CPP 2.5 runtime filters, AverageLuma, etc.)
New: Histogram("Levels"): add greyscale support

Thank you Ferenc. Weren't you supposed to take a break for a couple of weeks?

[pinterf]

No, I can't sleep well if I know that there are unfinished stuff. And I want to close this giant modification wave as soon as possible.

[Groucho2004]

Originally Posted by pinterf

No, I can't sleep well if I know that there are unfinished stuff.

I know the feeling. It can be unhealthy though.

[FranceBB]

Originally Posted by pinterf

Dear all, download
Avisynth+ v3.6.1 test build 5 (20200603)
Addressing mp_pipeline and further CPP 2.5 compatibility fixes (GRunT CPP 2.5 runtime filters, AverageLuma, etc.)
New: Histogram("Levels"): add greyscale support

Well I'm really sorry to say this 'cause you need some rest, but... it doesn't work. It starts allocating RAM and it creates the processes, however instead of showing the result, it outputs this error:

MP_Pipeline("""
ColorBars(848, 480, pixel_type="YV24")

### ###

""")

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

### platform: win32
### ###

""")

Same error.

MP_Pipeline("""
DirectShowSource("I:\Production\431.avi")

### platform: win32
### ###

""")

Same error.
(DSS 'cause I'm too lazy to wait ffms2 to index a test file).

I also tried it with a real script and it didn't work.

As to the Histogram() thing, well done updating it. I wonder if Histogram("color2") will get high bit depth in the future since it's currently limited to 8bit only.
No pressure at all, anyway. Take your time and have proper rest, you deserve it.

[pinterf]

And with a return last?
edit: before the last """ line

[manolito]

Results for 3.6.1 test 5: (only testing the x86 version)

HDRAGC still crashing with an access violation. This is under Win7-64 as well as under WinXP. Test version 2 has no problems with HDRAGC.

[FranceBB]

Originally Posted by pinterf

And with a return last?
edit: before the last """ line

Return last did solve the problem.
I even tried it with a real-world script and it worked just fine allocating its 4.3 GB of RAM and delivering the correct output:

MP_Pipeline("""
video1=DGDecode_MPEG2Source("\\VBOXSVR\Share_Windows_Linux\Production\RAW\424-430\opening_ending_textless.d2v")
audio1=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\424-430\opening_ending_textless T80 2_0ch 224Kbps DELAY 0ms.ac3")
AudioDub(video1, audio1)

opening=trim(0, 2715).ConvertFPS(23.976)

ending=trim(5436, 8175).ConvertFPS(23.976)

### export clip: opening, ending
### platform: win32

video2=DGDecode_MPEG2Source("\\VBOXSVR\Share_Windows_Linux\Production\RAW\417-423\421.d2v")
audio2=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\417-423\421 T81 2_0ch 224Kbps DELAY -115ms.ac3")
AudioDub(video2, audio2)

### export clip: opening, ending
### platform: win32

tfm(mode=1,pp=5,slow=2,micmatching=2,clip2=tdeint(mode=2,type=3)) 
tdecimate()
ConvertFPS(23.976)

### export clip: opening, ending
### platform: win32

opening++trim(2279, 6400)++trim(8799, 32938)++ending

### ###

Dither_convert_8_to_16()

### ###

nnedi3_resize16(target_width=1920, target_height=1080, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4,
threads=0, tv_range=true, kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=true, lsb=true)

### ###

dfttest(sigma=64, tbsize=1, lsb_in=true, lsb=true, Y=true, U=true, V=true, opt=0, dither=0)

### ###

ConvertFromStacked()

### ###

aWarpSharp2(thresh=180, blur=3, type=0, depth=35, depthC=10, chroma=4)

### ###

ConvertBits(bits=8, dither=1)

### ###

FastLineDarkenmod(strength=128)

### ###

f3kdb(range=15, Y=45, Cb=30, Cr=30, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false, 
opt=3, mt=true, keep_tv_range=true, input_depth=8, output_mode=1, output_depth=16)

### ###

nnedi3_resize16(target_width=3840, target_height=2160, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, 
pscrn=4, threads=0, tv_range=true, kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=true, lsb=true)

### ###

ConvertFromStacked()

### ###

Tweak(sat=1.51, dither=true)

### ###

ConvertToStacked()

### ###

s16 = last
DitherPost (mode=-1)

TextSub("\\VBOXSVR\Share_Windows_Linux\Production\Subs\Ep 421.ass")

Dither_convert_8_to_16 ()
s16.Dither_limit_dif16 (last, thr=1.0, elast=2.0)

### ###

ConvertFromStacked()

ConvertYUVtoXYZ()

ConvertXYZtoYUV(Color=1, pColor=2)

return last

""")

(you can't see some of the processes in the screenshot, though, but it works).

Originally Posted by manolito

Results for 3.6.1 test 5: (only testing the x86 version)

HDRAGC still crashing with an access violation. This is under Win7-64 as well as under WinXP.

I can reproduce that.

DirectShowSource("I:\Production\431.avi")

HDRAGC()

[pinterf]

Thanks, (and I found a buffer overflow for YUVA transfer in MP_Pipeline, but since this format is not much used yet, the priority for the fixed release is low).

[pinterf]

Daily test build 3.6.1-test6

Further v2.5 things (HDRAGC issue)
"return last" is not needed when script ends with a function definition

[gispos]

Originally Posted by pinterf

Daily test build 3.6.1-test6

Further v2.5 things (HDRAGC issue)
"return last" is not needed when script ends with a function definition

Yes, MP_Pipeline is running, but

dear pinterf, is that all because of the arrays?

I can only imagine a few things I could do with arrays (I'm just an average user).

But I don't want to exchange the loss of some plugins for it. I think I'm not the only one with this thought.
Did you really take the right path? In any case you have my sympathy.

[Gavino]

Originally Posted by pinterf

"return last" is not needed when script ends with a function definition

This has always been so, at least in 'classic' Avisynth.
(or is this a bug-fix for something that crept in recently?)

Simple test:

Version()
function f() { return 0 }

[StainlessS]

(or is this a bug-fix for something that crept in recently?)

Return Last requirement in mt_pipeline arose quite recently:- https://forum.doom9.org/showthread.p...56#post1906156

EDIT: Hmm, you cant quote from a previously Closed thread [eg old Avs+ thread]

By GisPos

MPP requires a 'return last' in the last section for NEO builds.

I take it MPP means mt_Pipeline. [EDIT: I mean MP_Pipeline]

[gispos]

Yes that related to MP_Pipeline.
I don't need a return last for this test version.
I didn't think that was bad either, you just had to know.

[FranceBB]

Originally Posted by pinterf

Daily test build 3.6.1-test6

Further v2.5 things (HDRAGC issue)
"return last" is not needed when script ends with a function definition

HDRAGC() now works fine:

#crappy simple test

video1=DGDecode_MPEG2Source("\\VBOXSVR\Share_Windows_Linux\Kyou kara Ore wa!! EP02 1080i.d2v")
audio1=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Kyou kara Ore wa!! EP02 T80 2_0ch 224Kbps DELAY 0ms.ac3")
Spline64Resize(704, 396)
sdr=last
hdr=HDRAGC()

StackVertical(sdr, hdr)

#for those script nazi (does such a word exist? like grammar nazi but for Avisynth scripts?)
# that lurked at the name of first file I found and indexed to make this simple stupid test
#and really wanna know why it's saying 1080i but I resized it without deinterlacing,
#the reason is that it's just 29.970 progressive flagged as interlaced

And I tried MPPipeline with the very same script I tried before but without the return last and it works without it now!
Very well done, Ferenc, just in time for the weekend.
You really deserve to rest now.

[manolito]

This latest 3.6.1-test 6 version looks like a winner to me...

HDRAGC now works under Win7-64 as well as under WinXP. Under XP I also tested it using all my old (and very very old) CPP 2.5 plugins, and all of them did not cause any problems.

MT stability is also very good. Right now I am running an encode on the WinXP machine (which has a single core CPU) with Prefetch(2), and it is slightly faster than without MT, and it is also stable. Kudos to pinterf...

[FranceBB]

Actually I gotta say that I found yet another thing... (sorry).
MPPipeline works, but if you go to XYZ and then come back to YUV it doesn't work...

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

ConvertBits(16)

### ###

ConvertYUVtoXYZ()

### ###

ConvertXYZtoYUV(Color=1, pColor=2)

""")

It's supposed to be showing color bars in BT2020 SDR YUV but it clearly isn't...
Of course if I make the conversion inside the very same block it works, but since you were asking about MPPipeline issues... well... this is one.
Of course, XYZ isn't officially supported by Avisynth as color space, so I don't know what Jean Philippe made inside his plugin to display it in Avisynth and work inside such a wide colorspace...
Anyway, this is one of the reasons why on the 25 of June 2018 I said that it would be nice in the future to have XYZ support inside Avisynth and perhaps one day it will happen... :')

[StainlessS]

Originally Posted by Gavino

This has always been so, at least in 'classic' Avisynth.
(or is this a bug-fix for something that crept in recently?)

Simple test:

Version()
function f() { return 0 }

No prob in v3.6.1 test6

EDIT:

You mean 3.6.1 test6, right?

Fixed

[manolito]

Originally Posted by StainlessS

No prob in v2.6.1 test6

You mean 3.6.1 test6, right?

[manolito]

Originally Posted by FranceBB

MPPipeline works, but if you go to XYZ and then come back to YUV it doesn't work...

Does this work under AVS+ 3.5.1?

Because if it does then pinterf has some more work to do, but if it doesn't then I think a more radical approach would be needed.