Avisynth+

[StainlessS]

Manolito link better than mine (I did not have All In One link handy).

You would likely need all of the dll's anyways (eventually).

[a1s2d3f4]

AIO link didn't have redistributable 2015.
I used StainlessS direct link to install those.
Also, I installed Universal Avisynth Installer [2018-12-22]. It mentions having the latest AVS+

[StainlessS]

Actually, I think that VS2017, and VS2015 runtimes are exactly the same (not sure, might be 2013 and 2015 same), but it would not do any harm to install both, maybe.
Groucho AVS AOI installer is real good, I'm in never ending process of installing dll's for v2.58, v2.60, avs+ x86 and x64 (partly because I'm updating my plugins to x64).
Remember to also use Groucho2004 AvsMeter to check plugins OK, and make REGULAR backups (when modding dll's) of the Videotools\AvisynthRepository\ directory.
Avs+ defo runs smoother, when sorted out, its just that it sometimes takes a while to get to the sorted out stage, especially if you've been running 2.5x up to now.

The old AVS+ from 1st post, is under control of Ultim, and he no longer visits, you aint the first to download the wrong/old version dll, think I probably did that too.

[pinterf]

VS2017 simply replaces VS2015 redistributables.

[wonkey_monkey]

I installed VS2017 alongside VS2013 recently and the resulting compiled filters were significantly (10-20% or so) slower than VS2013. Just thought I'd mention that in passing.

Anyway, to my point, which is a modest proposal.

I'm developing a filter which necessitates the passing of, for want or a better word, metadata between clips. Traditionally non-video data has been passed around as video in special clips, like MVTools's "super" clips, but this (not necessarily what MVTools does, but other filters doing similar things) is a bit of a bodge. Of course it's necessary because Avisynth has nothing for passing around data otherwise. I believe one of the DG tools uses the low bits of the first few pixels to pass data, for example.

What I'm doing with my new filter (and what I've previously done with warp (https://forum.doom9.org/showthread.php?p=1862943)) is abusing GetAudio. If it's called with start=1 and count=3, which is extremely unlikely to ever come up in the real world, and if the passed buffer starts with a special integer, then my code takes over and instead of filling the buffer with audio, it fills it with whatever information the child filter (backwards terminology from Avisynth's, don't get me started on that one) has requested by way of other data in the passed buffer.

By doing this, I can chain commands to add more and more metadata, all of which can be "bubbled up" to the ultimate descendant. Best of all it's completely transparent to VirtualDub2 (my viewer of choice) because all audio is passed through normally, so I only ever have one clip to pass to the actual "doing something" filter at the end of the chain.

But it still has some caveats, namely that audio filters can't be trusted not to destroy my metadata. And if a clip doesn't have audio to start with, it has to be added (and can't be removed until after the final filter runs).

So I was wondering if such a system could be implemented in Avisynth separate to GetAudio. GetData, perhaps. By just passing a pointer to a buffer - or maybe have one other integer parameter as well, for simplicity/flexibility - the system could be made extremely flexible but infinitely adaptable. For a start, custom clip properties would then be easy to implement as a plugin.

As far as I can tell all it would take is adding an extra member function to GenericVideoFilter which, by default, simply passes its parameter(s) down (up?) to the parent (the confusingly-named "child" in GenericVideoFilter), or, if there is no parent, does nothing. Filter writers can then override this to their heart's content.

Anyway, that's just my thought. Maybe it's a terrible idea for reasons which haven't occurred to me.

[pinterf]

I installed VS2017 alongside VS2013 recently and the resulting compiled filters were significantly (10-20% or so) slower than VS2013. Just thought I'd mention that in passing.

I'd say it cannot be slower and there must be a reason for that. 10-20% is an enourmous difference and cannot be explained by a simple difference in optimization.
I'd look at the generated assembler code.
Then, I think new projects in VS2017 are defaulting to handle spectre mitigation (https://devblogs.microsoft.com/cppblog/spectre-mitigation-changes-in-visual-studio-2017-version-15-7-preview-3/).
There can be a speed difference between MT and MD builds.
Check for possible AVX2-SSE2 transition penalties if any of your code has AVX2.

[wonkey_monkey]

I'd say it cannot be slower and there must be a reason for that. 10-20% is an enourmous difference and cannot be explained by a simple difference in optimization.
I'd look at the generated assembler code.

That's probably it. I didn't realise it had also been added to compilers.

Edit: further investigation suggests it isn't enabled by default, but also that the slowdown isn't as bad as I remembered. It's still slower with VS2017 though.

[pinterf]

That's probably it. I didn't realise it had also been added to compilers.

Edit: further investigation suggests it isn't enabled by default, but also that the slowdown isn't as bad as I remembered. It's still slower with VS2017 though.
I'm still interested in which type of code gets optimized worse in newer compilers. I suppose they are not simple simd optimized stuff.

[wonkey_monkey]

Maybe there are new optimisations which have slightly detrimental effects on older processors, or in certain circumstances. I expecting there are halting-problem type problems with trying to apply the best optimisations on all occasions.

The difference is slight enough that it could be any of several parts of my program. The busiest loop is full of ifs and switches and SSE.

[pinterf]

Maybe there are new optimisations which have slightly detrimental effects on older processors, or in certain circumstances. I expecting there are halting-problem type problems with trying to apply the best optimisations on all occasions.

The difference is slight enough that it could be any of several parts of my program. The busiest loop is full of ifs and switches and SSE.
For the busiest part of the code using templates (even for longer functions) can make wonders, avoiding thousand of ifs and switches in an inner loop has also big advantage on the optimization. Letting know the compiler to use constants (given as template parameters) instead of variables is also a big help. I don't know the actual situation but it would help a lot. Explicitely forceinlined functions can give further gain as well.

[manolito]

https://forum.doom9.org/showthread.php?p=1865439#post1865439

Sorry I spoke too soon, the joy only lasted for 3 weeks... :scared:

Last night I tried to convert a longer movie (2 and a half hours), and I got the crashes again. And it was reproduceable.

My AVS script:
DSS2("D:\Black Mass.mkv", fps=50.000, preroll=15)
Crop(0,0, -Width % 4,-Height % 4)
ColorMatrix(source=0,dest=2)
RequestLinear(rlim=50, clim=50)
ConvertToYV12()
Spline36Resize(704,396)
FDecimate(25)

# Start Remove Logo
Import("I:\Logo\Area.avs") #Defines the X and Y coordinates of the logo area
ConvertToYV12(interlaced=false)
Logo = crop(X1,Y1,X2-X1,Y2-Y1)
Above = Y1 > 0 ? crop(0,0,width(),Y1) : NOP()
Below = Y2 < height() ? crop(0,Y2,width(),height()-Y2) : NOP()
Left = X1 > 0 ? crop(0,Y1,X1,Y2-Y1) : NOP()
Right = X2 < width() ? crop(X2,Y1,width()-X2,Y2-Y1) : NOP()
ConvertToRGB32(Logo,interlaced=false)
LoadVirtualdubPlugin("E:\Programme\Virtualdub\Plugins\logoaway.vdf","VD_LogoAway")
# -----------------------------------------------------------------------------
VD_LogoAway( 3, 327685, 9895963, 0, 0, 5, 0, 66051, 131584, 10, "", "", "")
# -----------------------------------------------------------------------------
ConvertToYV12(interlaced=false)
IsClip(Left) ? StackHorizontal(Left, last) : NOP()
IsClip(Right) ? StackHorizontal(last, Right) : NOP()
IsClip(Above) ? StackVertical(Above, last) : NOP()
IsClip(Below) ? StackVertical(last, Below) : NOP()
last
# End Remove Logo

FineSharp()
avstp_set_threads(1)
Prefetch(4)
Trim(4248,161424)

This script is really not very complex. almosely's changes slowed it down quite a bit (adding Requestlinear after ColorMatrix and selecting MT_SERIALIZED for both ColorMatrix and RequestLinear), so the speed gain of MT was only about 1fps. Reducing the prefetch value to 2 did not make a difference, still I got crashes. Only disablng MT altogether made the script stable.

For my needs I do not see any advantage of using AVS+ over classic AVS 2.61. I reverted back to AVS classic, probably for good this time. (Unless someone comes up with a genius idea to use MT without crashes and still get a better speed).


Cheers
manolito

[VS_Fan]

... For my needs I do not see any advantage of using AVS+ over classic AVS 2.61. I reverted back to AVS classic, probably for good this time. (Unless someone comes up with a genius idea to use MT without crashes and still get a better speed).I remember some years ago having problems with frame decimation in a Multi-Threaded environment (old AVS-MT) and trying innumerable different configurations for ‘RequestLinear’ to no avail.

What I successfully ended doing was:

Separating only the source, decimation with any other ‘MT_SERIALIZED’ filters in one Single-Threaded AVS script, No need of of using 'requestlinear';
Then I either: ‘mounted’ that first script with AVFS; or simply read it directly with “AVIFileSource” into a second MultiThreaded AVS script where I put every other processing filters, susceptible of speed gains because of multi-threading

I don’t think this is genius idea, but I sincerely hope it helps :)

[an3k]

I have a Plugin (DGHDRtoSDR) that is not yet listed in the mtmodes.avsi and I would like to test (and add) it. I've searched but not found the info thus I asked here.

1) What is the "single-thread" mtmode in which every plugin perfectly runs at (since it's "non-MT-behavior")? Is it NICE_FILTER or SERIALIZED?

2) What is the most performant mtmode we would love to have all plugins running at? MULTI_INSTANCE?

Thanks :)

[TheFluff]

I remember some years ago having problems with frame decimation in a Multi-Threaded environment (old AVS-MT) and trying innumerable different configurations for ‘RequestLinear’ to no avail.

What I successfully ended doing was:

Separating only the source, decimation with any other ‘MT_SERIALIZED’ filters in one Single-Threaded AVS script, No need of of using 'requestlinear';
Then I either: ‘mounted’ that first script with AVFS; or simply read it directly with “AVIFileSource” into a second MultiThreaded AVS script where I put every other processing filters, susceptible of speed gains because of multi-threading

I don’t think this is genius idea, but I sincerely hope it helps :)

It's might be simpler than that. As far as I can tell FDecimate isn't in mtmodes.avsi, but since it's a m-in-n decimation filter it's almost certainly very stateful and not at all threadsafe. Setting it to MT_SERIALIZED might very well fix the crashing.

That said, the filter chain in that script is so full of ancient serialized junk so far down into the chain that the only thing of note that runs parallelized at all is FineSharp (I don't think vdub filters are MT_NICE? who knows though), so it's no wonder it's not any faster. As a reminder, inserting a MT_SERIALIZED filter into a filter chain will effectively cause every filter upstream of it all the way up to the source filter to run serialized too, at least as far as performance goes.

I have a Plugin (DGHDRtoSDR) that is not yet listed in the mtmodes.avsi and I would like to test (and add) it. I've searched but not found the info thus I asked here.

1) What is the "single-thread" mtmode in which every plugin perfectly runs at (since it's "non-MT-behavior")? Is it NICE_FILTER or SERIALIZED?

2) What is the most performant mtmode we would love to have all plugins running at? MULTI_INSTANCE?

Thanks :)

1) MT_SERIALIZED.

2) MT_NICE_FILTER.

See here (https://forum.doom9.org/showthread.php?t=174437) for more details. As mentioned above, using a MT_SERIALIZED filter late in a chain effectively disables MT (you'll be so bottlenecked that MT doesn't help you much).

If you're using Vapoursynth though you can get some degree of parallelism even with serialized Avisynth filters, which you can't do in Avs+ itself. In Avs+, calling GetFrame on a serialized filter will essentially run every filter upstream of that point single threaded too, so requesting a frame will make the entire thing block until the entire chain is finished processing that frame, one filter at a time in a single thread. In VS, you still get a single instance of the serialized filter (in its own pretend environment) and it will only ever be asked to process one frame at a time, but upstream of it can run in parallel.

[TheFluff]

I don't know who maintains the MT modes list anymore, or if the PublishWithMe pad is still the single source of truth, but colormatrix should, uh, probably not be marked as a MT_NICE_FILTER. The publishwithme pad itself notes that it seems very broken even when MT_SERIALIZED. Newer versions are internally multithreaded, and it's always done a lot of funky stuff internally (like requesting frames from the constructor and Invoke()'ing a lot of stuff).

That said, don't use colormatrix, it's always been a piece of buggy garbage.

[DJATOM]

Yeah, my friend used it in his scripts and it silently kills avs2yuv without any error. The only plugin that really piss me off...

[manolito]

...but colormatrix should, uh, probably not be marked as a MT_NICE_FILTER.

Did you have a look at this post?
https://forum.doom9.org/showthread.php?p=1865279#post1865279

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.


Applying these changes made my conversions a lot more stable, until a couple of days ago I got crashes again while converting a longer movie. Now I additionally specified MT_SERIALIZED for FDecimate, the first 2 conversions went well, let's see if it lasts...

[manolito]

Did some more speed benchmark tests using a long 2:40 movie (Heat by Michael Mann). I basically used the script from a couple of posts above. I did get a small speed gain by moving the FDecimate(25) call to the top of the script right after the source filter, and so far everything was stable.

I also tested the same source using z_ConvertFormat replacing ColorMatrix, RequestLinear and the built-in resizer. It worked nicely, but even in the default MT_MULTI_INSTANCE mode it was about 0.5 fps slower than the other script (ColorMatrix and RequestLinear both in MT_SERIALIZED mode). So as long as the script with ColorMatrix is stable for me I see no reason to ditch it.

For the SetMTMode.avsi I don't know if anybody is actively maintaining it. I uploaded my modified version here:
https://www.sendspace.com/file/3pdsc8
All comments were removed, also all MT_MULTI_INSTANCE calls were deleted (not necessary, MULTI_INSTANCE is the default).


Cheers
manolito

[poisondeathray]

So as long as the script with ColorMatrix is stable for me I see no reason to ditch it.



Quality wise, ColorMatrix produces color splotches and noise compared to higher quality methods. It's more noticable on animation , gradients ; less noticable on live action, film grain sources

[manolito]

Quality wise, ColorMatrix produces color splotches and noise compared to higher quality methods.

So far I am only aware of z_ConvertFormat as a "higher quality method" under AVS. Which other methods are you talking about?

Plus your statement about ColorMatrix producing color splotches and noise is quite new to me. So far I was only aware of Fluffy's statement that ColorMatrix was not suitable for MT under AVS due to questionable coding methods which offended his professional standards. Now you are talking about quality issues even when used in single threaded scripts.

Can you provide some proof of your statement? A source segment where a color conversion from Rec.709->Rec.601 reveals quality problems like color splotches and noise when using ColorMatrix?

[poisondeathray]

So far I am only aware of z_ConvertFormat as a "higher quality method" under AVS. Which other methods are you talking about?

Plus your statement about ColorMatrix producing color splotches and noise is quite new to me. So far I was only aware of Fluffy's statement that ColorMatrix was not suitable for MT under AVS due to questionable coding methods which offended his professional standards. Now you are talking about quality issues even when used in single threaded scripts.

Can you provide some proof of your statement? A source segment where a color conversion from Rec.709->Rec.601 reveals quality problems like color splotches and noise when using ColorMatrix?



Yes z.lib (z_ConvertFormat in avisynth), or AviSynthShader, probably Dither tools too. Basically anything else

709<=>601 either direction. Just compare ColorMatrix , it's easier to see on anime, cartoons . I'll post something tomorrow, there were some threads about this too.

[poisondeathray]

Can you provide some proof of your statement? A source segment where a color conversion from Rec.709->Rec.601 reveals quality problems like color splotches and noise when using ColorMatrix?




@manolito - RE: colormatrix quality issues
https://forum.videohelp.com/threads/391207-Converting-rec-709-to-rec-601

(the OP only provided screenshot, and it was converted back to YV12 for the "new" source but it's quite easy to see the problems)

Observations (not just this example, but in general):
- not version dependent, I tried a few colormatrix dll's , and the "ported" to ffmpeg filter exhibits the same issue. Probably partially due to 8bit conversion
- not settings dependent in terms of colormatrix clamping values (I usually set clamp=0 anyways, but pre/post clamp doesn't help)
- more noticable with certain color combinations , certain patterns that predispose to the issue. But source noise, film grain can often cover up the problems
- can occur 601=>709 too , eg. with DVD's when upscaling to HD . There were some DVD examples in other threads, I'll try to dig them up if you're interested
- the "better" high bit depth conversions are not because of dithering only (ie. it's not solely because of "covering up"); because if you disable dithering you still get "cleaner" image without the splotches and artifacts . But you can experiment with dithering algorithms back to 8bit . fmtc in vapoursynth has several options , it's easy to compare in avspmod tabs for example, with vsimport . avs+'s default convertbits(8) will use ordered dither .

[manolito]

Thanks for digging out the VideoHelp thread, I went over it quickly, but I could not reproduce the findings.

My sources are always 8-bit with 4:2:0 chroma. And the conversion from HEVC HD to AVC SD keeps the video this way. No dithering involved, and the color space also stays the same.

Also I only convert films, no anime. I went over some of my conversions which used ColorMatrix carefully, and I could not detect any color artifacts. So my only valid reason to ditch ColorMatrix and use z_ConvertFormat instead would be a better MT speed, and right now I do not get this.


Cheers
manolito

[pinterf]

avs+'s default convertbits(8) will use ordered dither .
ConvertBits does not dither, you have to specify dither=0 or dither=1.

[TheFluff]

I guess I should point to the elephant in the room and ask why you're even converting to Rec601 at all, when metadata flagging has been the preferred solution for at least a decade. I have a sneaking suspicion the answer probably involves some kind of arcane playback contraption from the late 1990's, though.

[lansing]

I guess I should point to the elephant in the room and ask why you're even converting to Rec601 at all, when metadata flagging has been the preferred solution for at least a decade. I have a sneaking suspicion the answer probably involves some kind of arcane playback contraption from the late 1990's, though.

He wanted to playback on his CRT TV

[manolito]

I have a sneaking suspicion the answer probably involves some kind of arcane playback contraption from the late 1990's, though.

How in the world did you know that? :devil:

My playback device is an older (around 2010) Xtreamer Sidewinder connected to my CRT TV. It does not handle H.265, but it plays H.264 just fine. This means that my captured HEVC streams need to be converted to AVC anyways, and while I'm at it I can just as well reduce the resolution to SD 704x396 and decimate the framerate from 50fps to 25fps. This looks good on my TV.

My knowledge of the Rec709 and Rec601 standards is limited, but conventional wisdom says that HD is Rec709 while SD is Rec601. My captured sources are all 1080p50 and flagged as 709, so I figured that I need to convert them to 601 when I convert them to SD.

The data sheet of my Xtreamer unfortunately tells me nothing about which color it expects. The only way to check for the correct color is to switch between playback of the original stream through the DVB-T2 receiver and the converted SD stream through the Xtreamer. And this comparison does not show any color differences, so I guess I am doing it right...

[Groucho2004]

This means that my captured HEVC streams need to be converted to AVC anyways, and while I'm at it I can just as well reduce the resolution to SD 704x396 and decimate the framerate from 50fps to 25fps. This looks good on my TV.

My knowledge of the Rec709 and Rec601 standards is limited, but conventional wisdom says that HD is Rec709 while SD is Rec601. My captured sources are all 1080p50 and flagged as 709, so I figured that I need to convert them to 601 when I convert them to SD.
I'd use DitherTools for that process.

Edit - Example (https://forum.doom9.org/showthread.php?p=1769274#post1769274)

[goorawin]

Here is a script that works really well at converting 1920x1080x50p to 720x576x25i (DVD standard). You may need to change the SelectEvery, to get the field order correct. Also change the sharpen to suit the source material.

bicubicresize(1440,1152)
bicubicresize(720,1152,-.8,.6)
bicubicresize(720,576,-.8,.6)
blur(0.0,1.0)
sharpen(0.0,0.75)
assumeBff()
separatefields()
SelectEvery(4,1,2)
Weave()
Matrix(from=709, to=601)

[Groucho2004]

Matrix(from=709, to=601)[/I]
Is that pseudo code or an actual function?

[goorawin]

It's a function. It does a similar and I think, a slightly better job to
ColorMatrix(mode="Rec.709->Rec.601")

[manolito]

I think he is talking about the HDRMatrix plugin from VideoArtifact:
https://www.videoartifact.com/hdr/

[goorawin]

Yes that is correct, it uses HDRMatrix

[StainlessS]

Hi P, as you seem to have been missing for a few days (Thanks for RemoveDirt mod), thought you may have missed this:- https://forum.doom9.org/showthread.php?t=176193

See comments in script and purple subtitles for 32 bit YV16.

[pinterf]

Hi P, as you seem to have been missing for a few days (Thanks for RemoveDirt mod), thought you may have missed this:- https://forum.doom9.org/showthread.php?t=176193

See comments in script and purple subtitles for 32 bit YV16.

Thanks, noticed too and fixed on git last month.
https://github.com/pinterf/AviSynthPlus/commit/07b95934351f3b0809f62a611768aa367ffbaacb

Busy times, not released yet.

[StainlessS]

see Comment in blue here:- https://forum.doom9.org/showthread.php?p=1869006#post1869006

Quote by StainlessS

EDIT:
Looks like CR_IsReallyFloatOld(InDAR) is a missing RaffRiff42 avsi function,
and it will only work as intended on v2.58, not v2.60+,
In v2.60+, Float args where user supplied as Int, they are forcibly converted to Float by Avisynth, and so that function has no purpose in v2.60 or Avs+.
Due to this forcible conversion, you cannot tell whether or not user called with float or int arg.
[I would have been happier if had been left as it was originally]

EDIT:


Function test(float "f") {
S = (f.Defined) ? "Defined" : "NOT Defined"
f=Default(f,42)
s = S + " F="+String(f) + "\n"
Return S
}

S0=VersionString+"\n"
S1=Test()
S2=Test(1)
S3=Test(2.0)

S= S0 + S1 + S2 + S3

BlankClip(width=240,Height=100)

Subtitle(S,lsp=0)


Avs v2.58
https://i.postimg.cc/tJ5jkSLK/Avs258.jpg (https://postimages.org/)

Avs 2.60(+)
https://i.postimg.cc/mDWWsWRx/Avs260-Plus.jpg (https://postimages.org/)

EDIT: In v2.60+, if the guy that wrote the script function supplied the default arg as an int, then can still produce problems and so the original fix conversion to float arg
still dont work ideally, ie maybe should also convert Defaulted args to Float where the formal arg type (think thats what its called) is of eg type float.
If this was done, then I would be happier.

[MysteryX]

Does Avisynth+ include the audio quality improvements of TimeStretchPlugin natively? (compared to the TimeStretch of AVS 2.6)

[manolito]

Yes, I believe it does...

v2.61 Updated SoundTouch library to 1.9.2. Fixes multichannel issues

[tebasuna51]

Just to be clear, correct me if I am wrong.

- TimeStretchPlugin is a old (2015) plugin by Wilbert (https://forum.doom9.org/showthread.php?p=1722472#post1722472) to improve the TimeStretch internal function of AviSynth 2.58 to add support for multichannel audio.

- Like manolito say AviSynth v2.61 update the TimeStretch internal function to SoundTouch library 1.9.2. Then TimeStretchPlugin is not needed for v2.61, only for v2.58.

- From the begining AviSynth+ have the TimeStretch function in a external plugin TimeStretch.dll (with SoundTouch library 1.9.2) supplied with AviSynth+

- BTW the SoundTouch library version is now 2.1.1 (https://www.surina.net/soundtouch/README.html). I don't know if the the last TimeStretch.dll from Avs+ is updated.

[manolito]

TimeStretch history as far as I remember:

AVS 2.60 internal TimeStretch function (forgot the SoundTouch version) only supports stereo audio, multichannel not supported.

Next was the TimeStretch Plugin by Wilbert:
changelog:
* version: 2.5.8.0 (requires AviSynth v2.58)
* filter is named to TimeStretchPlugin
* multichannel support
* updated SoundTouch library to 1.8.0
This version did support multichannel audio sources.

Then AVS 2.61 Alpha had an even newer internal TimeStretch version:
Update to SoundTouch 1.9.0(Wilbert+IanB).


For AVS+ the docs are really not very informative. In the AVS Wiki the Timestretch version info says:
v2.61 Updated SoundTouch library to 1.9.2. Fixes multichannel issues

Since classic AVS was not updated for years I suppose that this info applies to AVS+. But I could not find any info in the AVS+ docs about the current TimeStretch version. And the DLL itself does not have any embedded version info.

[Groucho2004]

But I could not find any info in the AVS+ docs about the current TimeStretch version. And the DLL itself does not have any embedded version info.
https://github.com/pinterf/AviSynthPlus/blob/MT/plugins/TimeStretch/SoundTouch/whence.txt

[tebasuna51]

Thanks Groucho2004, I can't remember where I read the Avs+ SoundTouch version but seems my memory still work a little.

[manolito]

ColorMatrix and alternatives under AVS+ MT

After many more tests using my Thinkpad Core i5 3rd generation (2 physical cores plus Hyperthreading) I think I know quite well what's going on here: :devil:

The good old tritical Colormatrix works well without crashes using the modifications suggested by almosely:
https://forum.doom9.org/showthread.php?p=1865279#post1865279

Colormatrix followed by RequestLinear, both in MT_SERIALIZED mode. I could not detect any artifacts of the kind described by PDR.

z_ConvertFormat uses MT_MULTI_INSTANCE through the SetMTMode.avsi (this is also the AVS+ default, no need to explicitly specify it). This might work for the z_Resizers, but if the matrix parameters are used, the script will crash. It needs MT_SERIALIZED for the matrix params.

For the HDRMatrix plugin the SetMTMode.avsi calls for MT_NICE_FILTER. This causes a crash immediately after starting the conversion. Specifying MT_MULTI_INSTANCE runs stable, but at a very low speed.

For me the old ColorMatrix plugin is the best so far. It is faster than the competition, and I did not detect any quality issues so far.

(I did not test DitherTools as suggested by Groucho. Way too complicated for me...)

Cheers
manolito

[pinterf]

https://github.com/pinterf/AviSynthPlus/blob/MT/plugins/TimeStretch/SoundTouch/whence.txt
Changed :)
I've updated SoundTouch with current git version (2.1.3) (today's achievement, exists only on my git, not released)

[GhostAFRippEr]

i have not activeted MT how to i add .avs script ?

[LigH]

How to use multi-threading in AviSynth+?

Read: Avisynth Wiki – AviSynth+: 3. MT Notes (http://avisynth.nl/index.php/AviSynth%2B#MT_Notes)

[qyot27]

It's been quite a while since the last time we tried this, so here's a GCC build of AviSynth+:
AviSynth+ (GCC) r2831-g316b54aa-20190321 (http://www.mediafire.com/file/s88qcoqcp108a0a/avisynth%252B-gcc_r2831-g316b54aa-20190321.7z)

And a corresponding pair of FFmpeg and mpv builds that include builds capable of handling otherwise-difficult 32-bit GCC builds of AviSynth+:
FFmpeg r93433+7 (http://www.mediafire.com/file/lj8zvwwg8mll1a2/ffmpeg_r93433%252B7.7z)
mpv r46865+11 (http://www.mediafire.com/file/7k1db8q3vxuc627/mpv_r46876.7z)

Unlike the previous GCC build of AviSynth+, it now will not interfere with your existing plugin folders. There is a separate registry entry and plugin folder path GCC builds look for, plugins+gcc. Examples below - change the path accordingly for where AviSynth+ is installed, but the point is that the plugins folder for GCC builds of AviSynth+ should be separate from the folder(s) for normal MSVC builds.

64-bit:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth]
@="E:\\Programs\\AviSynth+"
"plugindir2_5"="E:\\Programs\\AviSynth+\\plugins64"
"plugindir+"="E:\\Programs\\AviSynth+\\plugins64+"
"plugin+gcc"="E:\\Programs\\AviSynth+\\plugins64_gcc"
32-bit:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth]
@="E:\\Programs\\AviSynth+"
"plugindir2_5"="E:\\Programs\\AviSynth+\\plugins"
"plugindir+"="E:\\Programs\\AviSynth+\\plugins+"
"plugindir+gcc"="E:\\Programs\\AviSynth+\\plugins_gcc"

C-plugins should work with the GCC builds (the FFMS2 C-plugin definitely works). C++ plugins will not (excepting possibly if they were built with g++, but I've not tried this yet).

For those not wanting duplicate copies of FFMS2-C floating around, symbolic links should work fine.

[wonkey_monkey]

Help please - I'm trying to track down a bug but my lack of understanding of smart pointers is causing me a headache. The bug occurs if I use the following code in GetFrame:

PVideoFrame tmp = child2->GetFrame(n, env);
PVideoFrame src = child->GetFrame(n, env);

return src

In the constructor, the filter does something along these lines:

if ([condition]) child2 = env->Invoke(...); else child2 = child;

So child2 may, or may not, be the same clip (literally the same pointer) as child. When they are the same, I get unexpected behaviour, so I'm guessing there is something bad about calling GetFrame twice on the same clip.

So my question: is straight copying of a PClip like this an unambiguously wrong thing to do (I'm guessing it is), and if so, what's the correct thing to do?

[pinterf]

There is nothing wrong with copying PClips. In the above example, is tmp unused deliberately?

[jpsdr]

Is there MT mode used ? In that case, maybe affecting child2 in constructor is not compatible with MT_NICE ?