Avisynth+

[pinterf]

Historical moment, we could be the second and third one, spreading a new standard and increase the citation index of these formats. :)

[pinterf]

Me again...

colorbars returns a clip with alpha set to 255 with pixel_type="RGBAP8", but with pixel_type="RGB32", alpha is set to 0.
Thanks, fixed on git.

[pinterf]

libavcodec\raw.c includes these:
{ AV_PIX_FMT_GBRP, MKTAG('G', '3', 00 , 8 ) },
{ AV_PIX_FMT_GBRAP, MKTAG('G', '4', 00 , 8 ) },
So it at least looks similar to other G3/G4 formats, but probably there is no program to understand it.
Alpha on VfW was uninitialized because it wasn't filled.
Changed 8 bit planar RGB fourCCs similar to the 10-16 bit logic: G3[0][8] and G4[0][8]. I've prepared a test build for you (x64 only):
https://drive.google.com/open?id=1cmW5M2O3eEVOziWtAbxrJxmBgZMyZc-Y

[pinterf]

This test build in previous post has a working Layer filter for YUV 8-32 bit formats (except lighten/darken).
A new Layer parameter float strength (0.0 .. 1.0) optionally replaces the previous "level". This parameter is independent of bit-depth, one does not have to fiddle with it like had to with level (which was maxed with level=257 when RGB32 but level=256 for YUY2/YUV)
e.g. these pairs have similar effects

x=0
y=0
op = "add" # fast, subtract, mul
test422_1 = Layer(clip422, ovr422, op, strength=0.5, x=x, y=y, use_chroma=true)
testYuy2_1= Layer(clipYuy2, ovrYuy2, op, level=128, x=x, y=y, use_chroma=true)

test422_2 = Layer(clip422, ovr422, op, strength=1.0, x=x, y=y, use_chroma=true)
testYuy2_2= Layer(clipYuy2, ovrYuy2, op, level=256, x=x, y=y, use_chroma=true)

[shekh]

Alpha on VfW was uninitialized because it wasn't filled.
Changed 8 bit planar RGB fourCCs similar to the 10-16 bit logic: G3[0][8] and G4[0][8]. I've prepared a test build for you (x64 only):
https://drive.google.com/open?id=1cmW5M2O3eEVOziWtAbxrJxmBgZMyZc-Y

Thanks, everything looks good.

[pinterf]

Great, thanks. I'll arrange a release after having the Layer filter extension finished .

[StainlessS]

Is there some clip/colorspace property that denotes X and Y granularity for cropping, eg YV12 may crop on even boundaries both x and y,
and for YV411 multiple of 4 for x and 1 for y ?

Or does one have to inquire eg "Is420" and deduce that has same modulo requirements as YV12.

EDIT: Or extract Y plane and U plane and calculate it manually (last resort).

[Selur]

Does anyone know why SVP doesn't work with Avisynth+ (used 32bit, r2772, MT)? (https://www.svp-team.com/forum/viewtopic.php?pid=71384)
Works fine with 32bit Avisynth 2.6 MT.

[StainlessS]

Just checked converting 29.97 to 59.xxx and seems to work ok for me
InterFrame 2.8.1 by SubJunk,
svpflow1.dll File version=2.0.1.0, Product version 3.1.7 (~348KB)
svpflow2.dll File version=2.0.0.0, Product version 3.1.7 (~384KB)

avs+, r2772(32bit)

What are symptoms ?

[Selur]

Can you share those? I'd like to test whether those binaries work for me too.
(tried binaries from http://www.svp-team.com/files/gpl/svpflow-4.2.0.142.zip, also tried some other 4.x versions I found)

[StainlessS]

Yep:- http://www.mediafire.com/file/r37y2mztod68tro/SVP.zip/file
(32 bit only)

EDIT: Maybe I imagine it, but did SVP start requiring their own version of AVS+ at some point (I never really paid much attention).

[Selur]

Sadly those files also give me:
---------------------------
SVSmoothFps: unable to init GPU-based renderer
---------------------------
I used:
[code]LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow1.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow2.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\InterFrame2.avsi")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
# loading source: F:\TestClips&Co\files\test.avi
# input color sampling YV12
# input luminance scale tv
FFVideoSource("F:\TESTCL~1\files\test.avi",cachefile="E:\Temp\avi_078c37f69bb356e7b5fa040c71584c40_41_1_0.ffindex",fpsnum=25)
# current resolution: 640x352
InterFrame(GPU=true,NewNum=60,NewDen=1,Cores=32)
# filtering
PreFetch(16)
return last
When using AvisynthMT with:
SetMemoryMax(768)
SetMTMode(5,16) # changing MT mode
LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow1.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow2.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\InterFrame2.avsi")
# loading source: F:\TestClips&Co\files\test.avi
# input color sampling YV12
# input luminance scale tv
FFVideoSource("F:\TESTCL~1\files\test.avi",cachefile="E:\Temp\avi_078c37f69bb356e7b5fa040c71584c40_41_1_0.ffindex",fpsnum=25)
# current resolution: 640x352
SetMTMode(2) # changing MT mode
InterFrame(GPU=true,NewNum=60,NewDen=1,Cores=32)
distributor()
return last
everything works. (Side note: when using 'GPU=False' it works in both)

[StainlessS]

SubJunk has later version script (v2.8.2):- https://forum.doom9.org/showthread.php?t=160226

EDIT: And I've never used it much, and never with GPU=True.

[Selur]

Tried that one with the binaries it comes with.
Same result, GPU=True works fine with AvisynthMT, doesn't with Avisynth+.
never with GPU=True.
That explains why it works for you.

[wonkey_monkey]

Is there some clip/colorspace property that denotes X and Y granularity for cropping, eg YV12 may crop on even boundaries both x and y,
and for YV411 multiple of 4 for x and 1 for y ?

vi.GetPlaneHeightSubsampling(PLANAR_U);
vi.GetPlaneWidthSubsampling(PLANAR_V);


Is that it?

[pinterf]

Is there some clip/colorspace property that denotes X and Y granularity for cropping, eg YV12 may crop on even boundaries both x and y,
and for YV411 multiple of 4 for x and 1 for y ?

Or does one have to inquire eg "Is420" and deduce that has same modulo requirements as YV12.

EDIT: Or extract Y plane and U plane and calculate it manually (last resort).
No. I supposed that GetPlaneWidthSubSampling was available but is wasn't.

[StainlessS]

Thanks Wonkey, I know how to do that in C, was wantin' script solution.
EDIT: I usually work it out manually in C, as GetPlaneWidthSubSampling() not available in v2.58 (I think).

I have this in RT_stats


RT_ColorSpaceXMod(clip)
Return int, the natural cropping XMod for clip colorspace, eg YV411=4, YV12=2, YUY2=2, RGB=1
v2.5 plugin dll limited to v2.58 colorspaces.

***
***
***

RT_ColorSpaceYMod(clip,bool "Laced"=true)
Return int, the natural cropping YMod for clip colorspace, eg YV411=1, YV12=2, YUY2=1, RGB=1
Laced, bool. Default true. If Laced==true, returns doubled YMod.
v2.5 plugin dll limited to v2.58 colorspaces.


EDIT: Thanx Pinterf, I guess its coming :)

[pinterf]

Sadly those files also give me:
---------------------------
SVSmoothFps: unable to init GPU-based renderer [code 0x10000]
---------------------------

Setting the same SetMemoryMax(768) for the avs+ script helps?

[StainlessS]

I usually use InterFrame (seldomly) via a much larger script, and with GPU=False and cores=1, [some machines I use with same script are single core without GPU]
however, just tried

AviSource("D:\B.avi")
Interframe(GPU=True,NewNum=60000,NewDen=1001,cores=32)

works ok.
I only have quad core(Core 2 Q9550) , and crap GPU (Nvidia GT 520, my Dell Optiplex 780 limited to 6.5 inch cards, and total PSU only 300Watt, GT 520 5.5 inch, full load 29Watts).
No idea if it is actually using the GPU, or not.

EDIT: OK, we do seem to be using the GPU
https://i.postimg.cc/rzTWg2CX/nv-GT520.gif (https://postimg.cc/rzTWg2CX)

EDIT: For me, CPU is about 40% faster than GPU.
EDIT: In above graphic, shows GPU load at 8.0%, also memory controller load=11.0%, both seem a bit underused for some reason.
EDIT: And CPU usage about same whether or not GPU=True.

[wonkey_monkey]

Since we're talking about GetPlaneWidthSubsampling, it looks like there's an error on the Wiki (http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API/VideoInfo#GetPlaneWidthSubsampling_.2F_GetPlaneHeightSubsampling). YV16 should be 1/1 and YV411 should be 2/0. I think there are errors in both the table and the text.

I'd create an account and fix it myself but HTTPS doesn't work (which it really should in this day and age).

[pinterf]

Since we're talking about GetPlaneWidthSubsampling, it looks like there's an error on the Wiki (http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API/VideoInfo#GetPlaneWidthSubsampling_.2F_GetPlaneHeightSubsampling). YV16 should be 1/1 and YV411 should be 2/0. I think there are errors in both the table and the text.

I'd create an account and fix it myself but HTTPS doesn't work (which it really should in this day and age).
YV16 is 1/0

[StainlessS]

YV16 should be 1/1
YV16 should be 1/0 [text is back to front, but table is correct, methinks]
YV411 should be 2/0
agreed, table is wrong

EDIT:
Text is back to front

YV16: GetPlaneWidthSubsampling(PLANAR_U) = 0 // since there is no horizontal subsampling on a chroma plane
YV16: GetPlaneHeightSubsampling(PLANAR_U) = 1 // since vertically there are two times less samples on a chroma plane compared to a plane which is not subsampled

[Selur]

Setting the same SetMemoryMax(768) for the avs+ script helps?
Sadly no.
works ok.
simplifying the script to

LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow1.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow2.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\InterFrame2.avsi")
FFVideoSource("F:\TESTCL~1\files\test.avi",cachefile="E:\Temp\avi_078c37f69bb356e7b5fa040c71584c40_41_1_0.ffindex",fpsnum=25)
InterFrame(GPU=True,NewNum=60,NewDen=1,Cores=32)

doesn't help. Only thing that works is switching from Avisynth+ to old AvisynthMT. First thought it to be a driver issue, but threw that assumption out once I realized that it works with 32bit Avisynth MT.

[wonkey_monkey]

YV16 is 1/0

Well I blame my error on the whole stupid 4:2:2 system!

[Groucho2004]

Sadly no.

simplifying the script to

LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow1.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow2.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\InterFrame2.avsi")
FFVideoSource("F:\TESTCL~1\files\test.avi",cachefile="E:\Temp\avi_078c37f69bb356e7b5fa040c71584c40_41_1_0.ffindex",fpsnum=25)
InterFrame(GPU=True,NewNum=60,NewDen=1,Cores=32)

doesn't help. Only thing that works is switching from Avisynth+ to old AvisynthMT. First thought it to be a driver issue, but threw that assumption out once I realized that it works with 32bit Avisynth MT.I can't reproduce this problem. Can you upload the exact files you're using (ffms2.dll, svpflow*.dll, InterFrame2.avsi)?

[Selur]

here you go: https://drive.google.com/open?id=1w3aBlj3N9zdJGHrhEif5V4r8EA9goez8
using a GeForce GTX 1070 Ti with 418.81 drivers and a Amd Ryzen 7 1800X.

[pinterf]

Meanwhile a question regarding "Layer". I have the YUV stuff made ready but I experienced one little problem.

Layer mode: darken and ligthen is giving different results for RGB32 and YUY2 when Threshold>0

Even classic Avisynth 2.6.0.5 is giving different results for me.

Wiki:
http://avisynth.nl/index.php/Layer

E.g.: lighten:
"Copy overlay_clip over base_clip in areas where overlay_clip is lighter by threshold. Performs the same operation as add, but only when overlay_clip is BRIGHTER than base_clip."

And the relevant code from Avisynth+

Rgb32:

if constexpr(mode == LIGHTEN) {
alpha = luma_ovr > thresh + luma_src ? alpha : 0;
} else {
alpha = luma_ovr < thresh + luma_src ? alpha : 0
}


YUV:

if constexpr (mode == LIGHTEN) {
alpha_mask = (thresh + ovr) > src ? level : 0;
}
else {
alpha_mask = (thresh + src) > ovr ? level : 0;
}


The variable names are different a bit but one can see the difference. Sure, they are equivalent when thresh is 0.

Which computation covers the text definition?

Script to reproduce:

x=some source
x = x.Spline16Resize(512,256)
ovr=ColorbarsHD().Spline16Resize(x.width,x.height)
clipRgb = x.ConvertToRGB32(matrix = "PC.709").ResetMask()
ovrRgb = ovr.ConvertToRGB32(matrix = "PC.709").ResetMask()
clipYuy2 = x.ConvertToYUY2()
ovrYuy2 = ovr.ConvertToYUY2()

threshold=255 # 0 is O.K.
# which one works fine?
testRgb = Layer(clipRgb, ovrRgb, "lighten", level=128, Threshold=threshold)
testYuy2= Layer(clipYuy2, ovrYuy2, "lighten", level=128, Threshold=Threshold)

StackVertical(testRgb.ConvertToYV24(matrix = "PC.709"), testYUY2.ConvertToYV24())

[Groucho2004]

here you go: https://drive.google.com/open?id=1w3aBlj3N9zdJGHrhEif5V4r8EA9goez8
using a GeForce GTX 1070 Ti with 418.81 drivers and a Amd Ryzen 7 1800X.Using your files I can reproduce the problem on Win7 (in a VM -> VMWare generic graphics driver). Also, it crashes with every (2.6) Avisynth version, not just AVS+.

It works fine on XP/XP64 (GTX750, 350.12 driver). :confused:

[Selur]

Okay, for me it doesn't crash with Avisynth MT 2.6 (https://drive.google.com/open?id=1C0G_x5A4Wylf3k1zqFY7On5-_cLCaMj4), strange it crashes for all Avisynth 2.6 for you.

Cu Selur

[StainlessS]

Which computation covers the text definition?

"Copy overlay_clip over base_clip in areas where overlay_clip is lighter by threshold.

I would say this one.


// Rgb32:

if constexpr(mode == LIGHTEN) {
alpha = luma_ovr > thresh + luma_src ? alpha : 0;
} else {
alpha = luma_ovr < thresh + luma_src ? alpha : 0 // EDIT: Although I think this also wrong, see later.
}


EDIT:

isn't this for YUV lighten

alpha_mask = (thresh + ovr) > src ? level : 0;

equiv to this [if so then methinks obviously wrong]

alpha_mask = ovr > (src - thresh) ? level : 0;


EDIT: And is this correct for darken
Copy overlay_clip over base_clip in areas where overlay_clip is darker by threshold.

// Rgb32:

if constexpr(mode == LIGHTEN) {
alpha = luma_ovr > thresh + luma_src ? alpha : 0;
} else {
alpha = luma_ovr < thresh + luma_src ? alpha : 0

}

Should it be

alpha = luma_ovr < (luma_src - thresh) ? alpha : 0


EDIT: Or in full as here: (3 out of the 4 original lines look messed up to me)

//RGB:
if constexpr(mode == LIGHTEN) {
alpha = luma_ovr > (luma_src + thresh) ? alpha : 0; // As original
} else { // EDIT: DARKEN
alpha = luma_ovr < (luma_src - thresh) ? alpha : 0
}


//YUV:
if constexpr (mode == LIGHTEN) {
alpha_mask = ovr > (src + thresh) ? level : 0;
}
else { // EDIT: DARKEN
alpha_mask = ovr < (src - thresh) ? level : 0;
}


EDIT: I remember in some thread, that RaffRiff42 got some weird results from Layer, and could not figure out why, maybe this was it.

[pinterf]

EDIT: Or in full as here: (3 out of the 4 original lines look messed up to me)

//RGB:
if constexpr(mode == LIGHTEN) {
alpha = luma_ovr > (luma_src + thresh) ? alpha : 0; // As original
} else { // EDIT: DARKEN
alpha = luma_ovr < (luma_src - thresh) ? alpha : 0
}


//YUV:
if constexpr (mode == LIGHTEN) {
alpha_mask = ovr > (src + thresh) ? level : 0;
}
else { // EDIT: DARKEN
alpha_mask = ovr < (src - thresh) ? level : 0;
}



I spent too much time yesterday with not understanding what really happens and why my code produces different results than existing rgb version. I was thinking it over by a bottle of dark Staropramen :) and finally voted for this very same logic.

"Where overlay is brigher by threshold" =>
Where overlay is brigther by 10 =>
Where overlay > src + 10

and "Where overlay is darker by threshold" =>
Where overlay is darker by 10 =>
Where overlay < src - 10

[LigH]

Powered by beer™

[ajp_anton]

As far as comments concerned, below is demo of how handy '[* ... *]' is,

code...


Its use totally evaded me until RaffRiff42 pointed it out some time ago [I had even forgot that it existed as a comment option], the nesting comments can be very useful.

EDIT: Above is not prototype for current posted DDG, will be as above in next version.

But I would love to be able to do

Function DropDeadGorgeous(clip c,String DB,Int "ScanAhead", Int "X",Int "Y",Int"W",Int "H",Bool "Show", Bool "Verb",
\
\ Int "Prefilter", # Prefilter
\ Int "SPad", Int "SPel", Bool "SChroma", Int "SSharp", Int "SRFilter", # MSuper
\ Int "ABlkSize", Int "ABlkSizeV", # MAnalyse
\ Int "ASearch", Int "ASearchParam", Int "APelSearch", # MAnalyse
\ Bool "AChroma", Bool "ATrueMotion", # MAnalyse
\ Int "AOverlap", Int "AOverlapV", # MAnalyse
\ Int "ADct", Bool "ATryMany", # MAnalyse
\ Int "RthSAD", Int "RBlkSize", Int "RBlkSizeV", # MRecalculate
\ Int "RSearch", Int "RSearchParam", # MRecalculate
\ Bool "RChroma", Bool "RTrueMotion", # MRecalculate
\ Int "ROverlap", Int "ROverlapV", Int "RDct", # MRecalculate
\ Float "Iml", Bool "IBlend", Int "IthSCD1", Int "IthSCD2", # MFlowInter
\
\ Int "SOSthSCD2"
\ )


# is just a lot more handy when doing some quick coding, especially when you just want to quickly comment and un-comment a single line in the middle of a chain of \'s. And # is easier to write, with a european keyboard you need a lot of awkward keypresses with altgr for [ and shift for *.

[StainlessS]

@ajp_anton,

I imagine that your requirement would involve quite a lot of tricky work and probably at multiple places in the parser source code (with potential for lots of new and exciting bugs for the user, even in long existing scripts).
EDIT: Not sure if it would be worth the risk.

[almosely]

Hi,

after migrating from AviSynth 2.6.0 MT (SEt) (x86) to AviSynth+ 0.1.0 r2772 MT (x64) - and changing some filters - I discovered some things, that should be helpful to know for everybody else.

1) I switched from DGSource (from DGDecNV 2052) to DGSourceIM (beta 50) and discovered, that DGSourceIM is very unstable in general. Whether I used AVS 2.6.0 (x86) in ST/MT-Mode or AVS+ (x64) ST/MT, my encodings crashed (started with Simple x264 Launcher) at random times (error message something like "encodin process is not responding anymore" within Simple Launcher), but only full encodes, never compression or AVSMeter tests. So I switched back to DGSource and let my GeForce GTX 660 Ti do the decoding job. That is completely stable again.

2) I tried to save energy. That has been the reason in first place to switch to AVS+ and exchange DGSource against DGSourceIM too (I have a Core i5-3470 CPU with integrated Intel HD Graphics 2500 iGPU). To get that running, I have to enable Multi-Monitor-Support for my iGPU within my ASUS-BIOS (as the second GPU) and than enable a second imaginary screen output within Windows 7 to the HD Graphics, so that QuickSync (and the iGPU in general) became available at all. I did that becaus the GTX consumed 24 Watts extra only for decoding with DGSource and another 9 Watts extra for using FFT3DGPU. DGSourceIM is using just 1 Watt extra for the decoding job and FFT3DFilter (CPU based) is slowing down the encoding just 9%. So I was saving aprox. 30-50% of energy for the encoding task in the end. But, because of the strong unreliability of DGSourcIM I had to switch back the DGSource (and my GTX). Then I discoverd, that the GTX is switching from it's P8 Performance State (lowest) to P0 (highest) at the moment of using DGSource or FFT3DGPU, which results in that tremendously insane energy consuming. It is not switching away from P8 when decoding video-clips within Firefox, but it is also switching when using LAV-Filters within MPC-HC btw. So, I discovered a neat function of the Nvida Inspector tool, called Multi Display Power Saver (available through right-clicking the button "Show Overclocking"). Within there I restricted the GTX to the permanently use of the P8 Performance Level and let the Multi Monitor Power Saver autostart with Windows 7. That reduced the power consuming to the level of using the HD Graphics for decoding with DGSourceIM, but using DGSource of course. And there are no setbacks at all by letting the GTX running with P8 state permanently. There's also an option, to let the GTX run with either P5 or P0, when a specific .exe file is running, so just put the .exe of a game etc. as an exception there, and everythin runs fast and sound where it's needed. FFT3DGPU is running too slow with P8-State, but maybe fast enough with P5 - but, I do not use FFT3DGPU anymore, because FFT3DFilter is saving much more energy and is way better quality wise.

3) While getting used to AVS+ I discovered the mtmodes.avsi file, where a lot of MT-Modes are tested and predefined already. There's the need to change something (for everybody):

SetFilterMTMode("CompTest", MT_SERIALIZED)
SetFilterMTMode("ColorMatrix", MT_SERIALIZED)
SetFilterMTMode("RequestLinear", MT_SERIALIZED)
SetFilterMTMode("GradFun3", MT_MULTI_INSTANCE)

and remove the the following at the very end:

if (FunctionExists("avstp_set_threads")) {
# this isn't actually optimal, because it will also disable avstp threads if running
# on a single-threaded filter chain
avstp_set_threads(0, 1)

and put instead the following line within your personal .avs-script at the end, right before Prefetch(), but only when activating MT-Mode (using prefetch).

avstp_set_threads(1)

AVS+ is running faster (and still stable) when letting avstp do it's internal mt-job when using GradFun3-Filter in ST-Mode. There's no need to deactivate it in general, only for MT. And this line has to be set at the "very" end of the avs-script, as pointed out by the developer of avstp.dll. It is working - I tested it with AVSMeter by watching the amount of threads.

ColorMatrix is running absolutely fine in MT-Mode within AVS+ (x64), but only it it's placed within a bubble of sequential frame order. So, to ensure that, RequestLinear has to be used and to be defined as MT_SERIALIZED. It makes no sense to use RequestLinear as MT_MULTI_INSTANCE. Therefore the following sript is working totally fine for me (I tested it multiple times with ST and MT encodings of the same clip) - no differences within the x264 logfiles. I did encounter differences when not using RequestLinear as MT_SERIALIZED of course.

DGSource()
CompTest(5, 60)
ColorMatrix(hints=true)
RequestLinear(rlim=50, clim=50)
...
avstp_set_threads(1)
Prefetch(3)
return last

That's working just fine as an example.

[videoh]

1) I switched from DGSource (from DGDecNV 2052) to DGSourceIM (beta 50) and discovered, that DGSourceIM is very unstable in general. True. DGDecIM is deprecated due to crappy Intel support/drivers. I should withdraw it.

Thank you for your interest in DG tools!

[DJATOM]

True. DGDecIM is deprecated due to crappy Intel support/drivers. I should withdraw it.

Thank you for your interest in DG tools!

Well, I hope you'll add SW decoding in DGDecodeNV someday or implement another tool for that. We only have LWLibavSource and DGDecodeIM(..., engine=2) options for encoding on servers w/o NVidia GPU.

[manolito]

@ almosely

Thanks very much for your post about AVS+ settings and mtmodes.avsi. The settings you suggested seem to completely avoid the crashes I had with AVS+ so far... :D

I often convert my DVB-T2 TV captures from HD HEVC to SD AVC (old school like yourself, I still watch my movies on a CRT TV set). I use StaxRip (older 32-bit version), my AVS scripts are quite basic, and I was interested in AVS+ solely for some speed gains through the MT capability. High bit depth and fancy color spaces are not my thing. I also use 32-bit tools exclusively, my laptop is a ThinkPad with a Core i5 3rd generation CPU and 8GB RAM.

But up to now I could not get it stable with AVS+, I randomly got crashes just like the ones you described (Win7-64). This happened with and without the mtmodes.avsi, taking out filters one by one did not help, only way to get it stable was to disable MT. So I repeatedly reverted to good old AVS 2.61.

Last night I applied your suggested changes and did 2 long conversions, and to my surprise everything was absolutely stable. Of course I need to do more conversions to be sure, but it does look very promising. I have no idea which one of your suggestions did the trick, though. My script does contain ColorMatrix, maybe this was the culprit. The other thing which really surprised me was that avstp_set_threads made a difference. For all I know my script does not use any avstp-aware filter, still the encode got a little bit faster when I added the command before the prefetch call. Do you have an explanation?

Whatever, thanks again for your tips. You should update the mtmodes.avsi here:
http://avisynth.nl/index.php/AviSynth%2B#Help_filling_MT_modes

so others can profit from the changes, too.


Cheers
manolito


//EDIT//
Oops, I forgot one thing...
All of the above is for using DSS2Mod as my source filter. My overall speed increase by using AVS+ with these settings is about 1fps for 4 threads. With 3 threads the speed is almost the same.

But when using ffms2 as my source filter (latest stable GitHub version 2.23.1) the encoding speed drops considerably after a few minutes into the encode. About 5fps slower than with AVS 2.61. Not good, what could cause this?

[Groucho2004]

But when using ffms2 as my source filter (latest stable GitHub version 2.23.1) the encoding speed drops considerably after a few minutes into the encode. About 5fps slower than with AVS 2.61. Not good, what could cause this?Have you tried the "threads = 1" parameter with ffms2?

[almosely]

@manolito

You're welcome! Nice, I could help someone with my discoveries :-)

[GMJCZP]

I took the liberty to prepare mtmodes based on almosely's observations. I post it here and not on its corresponding page to continue the tests and subsequent discussions. Thanks almosely.

Here (https://www.filedropper.com/mtmodes02122019_1)

[manolito]

Have you tried the "threads = 1" parameter with ffms2?

Thanks for the tip, I tried it, but this parameter really backfired... :scared:

With the default "threads=-1" which uses the number of logical cores reported by Windows (4 in my case) I got a speed of 21.47 fps. Using "threads=1" the speed dropped to 15.66 fps. With DSS2Mod the speed was 24.49 fps.

After many more speed benchmark tests I can say that the AVS+ MT feature is not all that useful when using very basic AVS scripts which I usually do. The real speed difference gets obvious when using more complex scripts like the MysteryX FrameRateConverter script. This script makes extensive use of MVTools, and here I get a speed difference of almost 80%.


Cheers
manolito

[LigH]

Hint: FFMS2 and L-SMASH Works may use different splitters, which also affects the following decoder. So compare FFVideoSource with LwLibavVideoSource (and possibly even LSMASHVideoSource for ISO Media containers, like MP4 / MOV / 3GPP) too.

[manolito]

Yes, I will check this out on my next conversion later tonite...
Can you recommend a version which causes the least possible problems? (including download link) And would LSMASHVideoSource work for HEVC in an MKV and TS/MTS container?

[LigH]

1. MeGUI provides a well tested version. I won't guarantee for "the best that there is", though. Unfortunately, it is not regularly rebuilt, and the most recent version (https://forum.doom9.org/showthread.php?p=1843162#post1843162) may have some flaws (e.g. using AviSynth 2.5 headers).

2. No, LSMASHVideoSource does not support MKV or TS containers, only containers compliant to the ISO base media file format (https://en.wikipedia.org/wiki/ISO_base_media_file_format). For all other containers, you will need LwLibavVideoSource using the libavformats demultiplexers and its indexer. Decoding HEVC should be supported.

[StainlessS]

ISO base media file format


Function IsISOFileName(String s) { s=Lcase(RT_GetFileExtension(s)) Return(s==".mov"||s==".mp4"||s==".3gp"||s==".3g2"||s==".mj2"||s==".dvb"||s==".dcf"||s==".m21")}

If you dont use RT_, maybe make your own "GetFileExtension, reverse string, look for '.', chop off extension, reverse extension.

[manolito]

Thanks LigH for your LSMASH links.

I did a couple of speed benchmark tests using the usual source filters (sorry, no DG filters), and these are the results:

Source was again a captured German DVB-T2 file. 1080p HEVC at 50 fps, converting it to SD AVC using StaxRip. Very basic AVS script, it did include ColorMatrix and the VDub filter Logoaway. Everything 32-bit. Using the current AVS+ MT 32-bit build, added the almosely tweaks to the MTModes.avsi. Using 4 threads on my Core i5 3rd generation everything runs stable, no crashes.

FPS tests were done with the latest X264 build by LigH, I want to test the overall speed, just testing the script with AVSMeter is misleading for me.


DSS2Mod (preroll=15) : 25.83
ffms2 2.23.1 : 22.91
ffms2000 test 8 : 23.04
LWLibav r784 XP : 24.40
LWLibav r929 : 24.44
LWLibav r941 : 24.41

All FPS measurements were taken at 10% into the encode. The clear winner is DSS2Mod followed by LWLibav. The old XP version which does not even need SSE2 is just as fast as the later versions.


Cheers
manolito

[wonkey_monkey]

Some more errors on the Wiki?

http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API/VideoInfo#IsRGB_.2F_IsRGB24_.2F_IsRGB32

bool IsRGB() const;
bool IsRGB24() const;
bool IsRGB32() const;

All of them will return true if the colorspace is RGB (in any way). The last two return true if the clip has the specific RGB colorspace (RGB24 and RGB32).

That can't be right, can it? Same just below:

bool IsYUV() const;
bool IsYUY2() const;
bool IsYV24() const; // v5
bool IsYV16() const; // v5
bool IsYV12() const;
bool IsYV411() const; // v5
bool IsY8() const; // v5

All of them will return true if the colorspace is YUV (in any way). The last six return true if the clip has the specific YUV colorspace (YUY2, YV24, YV16, YV12, YV411 and Y8).

Maybe I'm missing something but I don't think that makes sense.

[Groucho2004]

bool IsRGB() const;
bool IsRGB24() const;
bool IsRGB32() const;

All of them will return true if the colorspace is RGB (in any way). The last two return true if the clip has the specific RGB colorspace (RGB24 and RGB32).

That can't be right, can it?
Makes sense to me (as does the YUV logic). Can you elaborate on your objection?

[wonkey_monkey]

"All of them will return true if the colourspace is RGB (in an way)"

If that's true, then they would all be true whether it's RGB24, RGB32, or Planar RGB. Which means you'd have no way to distinguish RGB24 and RGB32.