Avisynth+

[innocenat]

Just stating in this topic also: the above issues happens in r1561 but not r1576. No fix needed. Refer to linked topic for more information.

[TurboPascal7]

Some testing done this afternoon with 1080P material.
The following hangs in MeGui preview:
LoadPlugin("D:\eseguibili\media\DGDecNV\DGDecodeNV.dll")
SetFilterMTMode("", 2)
SetFilterMTMode("DGSource", 3)
DGSource("E:\in\something.dgi")
#CompTest(1)
ChangeFPS(last,last,true)
SMDegrain (tr=6,PreFilter=2,thSAD=600,contrasharp=false,refinemotion=true,lsb_out=true,plane=0,chroma=false,Globals=2)
SMDegrain (tr=6, thSAD=600,contrasharp=false,refinemotion=true,lsb_in =true,plane=0,chroma=false,Globals=1,mode=6)
Prefetch(3)
Both works ok under AviSynth_MT from Set, which is even a bit faster.
I can confirm it being very slow (on 1080p) and probably unstable but it doesn't hang out completely for me in avspmod. Please try to remove SetFilterMTMode("", 2) line and see if it works (performance aside). This is most likely caused either by some globals magic or wrong mt mode specified for some filters.

mpeg2source doesn't seem to work with avs+ mt on. I have a 1080p mpeg2 video which I indexed with dgindex, and trying to test with mt on, it gave me a green screen onload with avspmod, and when I try seek, the program just hangs. All three mt mode will hang.


SetFilterMTMode("MPEG2Source", 2)
MPEG2Source("sample.d2v", cpu=0)
Prefetch(4)

Can't reproduce. Mode 1 is indeed broken but that's to be expected. Modes 2 and 3 work without issues here. Does it happen with some specific source or any sources in general?

Most tests finished OK but the most basic test failed: Avisource input only.
Frames seem to have a wrong pitch.
Source is RGB in an AVI container.
Used script:
s = AVISource("part2.avi")
s = ConvertToYV12(s)
return(s)

Source can be found here (http://hank315.nl/files/part2.7z).

Reproduced, reposted (https://github.com/AviSynth/AviSynthPlus/issues/36)on github. Avisource indeed can't handle mod32 pitch in this case. I will look into later this week.

pinterf
Firesledge added functions from dither here (https://pad.riseup.net/p/avs_plus_mt_modes) and they all seem to be NICE_FILTERs, so I guess the issue is somewhere in mvtools2. I'll probably play with it some time soon but wouldn't mind anyone testing it before me.

[ultim]

But if you think about it, this API design is very bad. Most users don't know and don't need to know the difference between prefetching threads and the main thread. Adding Prefetch(4) to their script, they absolutely reasonably expect it to work in 4 threads, trying to explain to them that it's actually 5 would be silly. So this bug kinda makes the API better.

I kindly disagree and will keep it this way even in the future. Hopefuly I will also find why Prefetch(1) is the same as Prefetch(0) and fix it.

Why I think it is better this way? First, the name of "Prefetch" is well chosen, because it describes exactly what the filter does: it prefetches frames. When inserted into a script, the user is basically telling the core a command to "Prefetch me frames in addition to the one you are working on now!". So the name is fine. So when you see the function declared as "Prefetch(nThreads)", what is the most intuitive way to interpret it? Isn't the first thing you think of "prefetch using nThreads threads"? I think it is, and this is exactly what AviSynth+ is doing now. Going TurboPascal's way would mean "Prefetch frames for me using one less threads than what I told you"! That is way more counterintuitive than the current implementation.

I do agree with TurboPascal that users shouldn't need to concern themselves with implementation details. They shouldn't, which is why I find it odd at all that he explained this. A higher number gives more threads: that is IMHO no less and no more than what a user must know in this case to find the optimal parameter for his number of cores, for best performance on his computer.

As for bugs, please remember, there is a reason this was published as a test build.

[ultim]

Well, bad news folks, we didn't get accepted for GSoC this year. Of course our "staff" will remain available for anybody wishing to pick up one of the projects, for help. There is always a next year, and we continue to hack around AviSynth ourselves too.

The preparation for GSoC was not all in vain though. We discussed a lot of things about the future of AviSynth's ecosystem. Thanks to GSoC, we managed to define what we want to do, defined our priorities and wishes clearly. As "by-products", we even got ourself a nice set of coding guidelines for future contributions, and improved our infrastructure just a bit further. Also, now that GSoC isn't playing for us in 2014, I can extend our ideas list with all those that we did discuss and want to have, but for various reasons deemed unfit for Google.

[TurboPascal7]

I kindly disagree and will keep it this way even in the future.
We can go full democracy and ask users to vote. Question is: "how many threads do you expect the following script to have? Assuming no filters are multithreaded internally."
DgSource("commie.dgi")
tfm().tdecimate()
debilinear(1280, 720)
gradfun3()
Prefetch(4)
My answer is 4. It's perfectly reasonable that you like your implementation (you wouldn't write it this way in the first place otherwise), but I believe it's non-obvious for anyone without programming experience.

[MasterNobody]

I don't see anything bad with having 5 threads when using Prefetch(4) if all hard work is done by this prefetch threads and one more (main) light thread is only needed to orchestrate other threads. That is mostly semantic of what x264 have for --threads and the only exception is --threads 1 when main thread and working threads become the one and the same thread.

[TurboPascal7]

I don't see anything bad with having 5 threads when using Prefetch(4) if all hard work is done by this prefetch threads and one more (main) light thread is only needed to orchestrate other threads. That is mostly semantic of what x264 have for --threads and the only exception is --threads 1 when main thread and working threads become the one and the same thread.
There's nothing wrong with having five or even more threads if all but four of them are idling most of the time, that's a minor implementation detail. But I thought the plan was to have main thread doing the same kind of stuff prefetch threads are doing (e.g. main thread requests frame 0, prefetch threads request frames 1, 2, 3 and 4).

[lansing]

Can't reproduce. Mode 1 is indeed broken but that's to be expected. Modes 2 and 3 work without issues here. Does it happen with some specific source or any sources in general?


mode 2 and 3 were fine with 480p source, but not for 1080 mpeg2 videos, I tried on a few clips already. This time only prefetch(0) work, all other prefetch would gave a green screen, and then after a few jumps in timeline, the program would hang.

[TurboPascal7]

mode 2 and 3 were fine with 480p source, but not for 1080 mpeg2 videos, I tried on a few clips already. This time only prefetch(0) work, all other prefetch would gave a green screen, and then after a few jumps in timeline, the program would hang.
Reproduced, thanks for the report.

[lansing]

Another problem, I tired running mctd script on a 1080 avc stream. I loaded the script into virtualdub and ran analysis pass, and it returned an error "could not allocate video frame. Out of memory".


dgsource("test.mkv", engine=1)
mctd()

[cretindesalpes]

I had this problem several times recently (using MT r1689) with scripts working perfectly with the vanilla Avisynth but failing to allocate frames in Avs+. Increasing the SetMemoryMax value is generally enough to make them work, but it also increases the overall memory usage, and you might end up closer to the fatal 4 GB barrier for a 32-bit process.

Maybe that releasing the cached frames from filters not used for a long time (for example after N GetFrame calls) would help? At least in my case there was important conditional filtering involved (lots of filters used once in a while) or long FFVideoSource+FFVideoSource+... chains.

[pinterf]

pinterf
Firesledge added functions from dither here (https://pad.riseup.net/p/avs_plus_mt_modes) and they all seem to be NICE_FILTERs, so I guess the issue is somewhere in mvtools2. I'll probably play with it some time soon but wouldn't mind anyone testing it before me.

1.) It says 1.25 version tested, typo? I know only Dither 1.24.

2.) Replaced mvtools2.dll from 2.6.0.5 of Dither 1.24 package => version 2.5.11.2 2011.04.18.
Now AVS+ works flawlessly.

Somehow mvtools2 2.6.0.5 causes Dither_Resize16 hang and give "Dither_resize16: resizing ratio too low or kernel support too high" message

3.) interesting (for me)
Setting MSuper to MT_NICE_FILTER instead of MT_MULTI_INSTANCE caused the first %Prefetch% frames currupted: they are dark/still noisy/ghosty


# some globals for the clip
play_speed=16
trim_begin=0 #120
seconds=120
trim_end=trim_begin + play_speed*seconds
_grey=false
film="c:\Tape13\Videos\1975_KeskenyFilm.avi"
#720x576 8mm film transfer

# AVS+ version
#SetFilterMTMode("", MT_MULTI_INSTANCE) #NOOO! Bad idea.

# SetFilterMTMode("Dither_Resize16", MT_SERIALIZED)
# MT_MULTI_INSTANCE/MT_NICE_FILTER Hangs with mvtools2 from 2.6.0.5 Dither package 1.24 )
# Error: "Dither_resize16: resizing ratio too low or kernel support too high"

SetFilterMTMode("Dither_Resize16", MT_NICE_FILTER) # with mvtools 2.5.11.2 NICE_FILTER_OK

SetFilterMTMode("DitherPost", MT_NICE_FILTER)
SetFilterMTMode("MDegrain2", MT_MULTI_INSTANCE)
SetFilterMTMode("MAnalyse", MT_MULTI_INSTANCE)
SetFilterMTMode("MRecalculate", MT_MULTI_INSTANCE)
SetFilterMTMode("MSuper", MT_MULTI_INSTANCE) #when NICE filter, the first %prefetch% frames bad: noisy/ghosty/dark

#Load plugins explicitly
#-----------------------
DLLPath="..\8mmDLLs\"
Loadplugin(DLLPath+"mt_masktools-25.dll") #Version 2.0.48.0 2012.04.02 needed for Dither_ package
Loadplugin(DLLPath+"dither.dll") #Version 1.24 2013.10.26
Import(DLLPath+"dither.avsi")
LoadPlugin(DLLPath + "mvtools2.dll") # Version 2.6.0.5 2012.07.17 from Dither 1.24: MT hangs Dither_Resize16 on AVS+
# version 2.5.11.2 works! 2011.04.18
LoadPlugin(DLLPath+ "Rgtools.dll") # tp7 alternative new package for Clense, RemoveGrain

#keep it the last line please
if (FunctionExists("avstp_set_threads")) {
avstp_set_threads(0, 1) #disable threading in dither
}

#################################
# load video
#################################
Avisource(film).killaudio().assumefps(play_speed).trim(trim_begin,trim_end).converttoYV12()
clp=last

#--------------------
#-- Start of MDegrain part.
# variables for denoising (MDegrain)
denoising_strength= 600 #denoising level of first denoiser: MDegrain()
block_size= 8 #block size of MVDegrain
block_over= 4 #block overlapping

prefiltered = Removegrain(clp,mode=2)
superfilt = MSuper(prefiltered, hpad=32, vpad=32,pel=2)
super= MSuper(clp, hpad=32, vpad=32,pel=2)

halfblksize= (block_size>4) ? block_size/2 : 4
halfoverlap= (block_over>2) ? block_over/2 : 2

bvec1 = MAnalyse(superfilt, isb = true, delta = 1, blksize=block_size, overlap=block_over,dct=0,chroma= _grey ? false : true)
bvec1 = MRecalculate(super, bvec1, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

fvec1 = MAnalyse(super, isb = false, delta = 1, blksize=block_size, overlap=block_over,dct=0,chroma= _grey ? false : true)
fvec1 = MRecalculate(super, fvec1, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

bvec2 = MAnalyse(super, isb = true, delta = 2, blksize=block_size, overlap=block_over,dct=0,chroma= _grey ? false : true)
bvec2 = MRecalculate(super, bvec2, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

fvec2 = MAnalyse(super, isb = false, delta = 2, blksize=block_size, overlap=block_over,dct=0,chroma= _grey ? false : true)
fvec2 = MRecalculate(super, fvec2, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

#mvtools2 2.6.0.5 or 2.5.11.2
clp.MDegrain2(super, bvec1,fvec1,bvec2,fvec2,thSAD=denoising_strength)
GreyScale()
#-- End of MDegrain part
#---------------------------

Dither_Convert_8_to_16()
Dither_Crop16(16,16,-16,-16) # just to have a crop and resize
Dither_Resize16(720,576) # back to original for the sake of demo
DitherPost()

#for AVS+ enable MT
Prefetch(8)

[lansing]

I have some confusions with the mt mode. Let say if I have two filters, filter A and filter B. Filter A runs optimum at 5 threads, and filter B runs optimum at 7 threads. Then how many threads do I call at the end of the script? If I have prefetch(7) then filter A will be wasted, but if I have prefetch(5), filter B will be slowed down?

[cretindesalpes]

pinterf:

I tried your script and I can confirm it crashes or hang with dither.dll from Dither 1.24.0.
However it works with the new 1.25.0. I will release it soon.

[lansing]

I ran into a access violation error with this simple script


AVISource("sample.avi")
stab()
a = last
b = fft3dgpu(sigma=5)

mt_merge(a, b.mt_edge())


When I try to jump to another frame in timeline, a pop up error say "error requesting frame N, WindowsError: exception: access violation reading 0x00000002". When I replace fft3dGPU with fft3dfilter, the error go away.

[bxyhxyh]

Is there any list or Readme about avs+ functions?
I don't know any avs+ functions.

[ultim]

Just installed Avisynth+ to run some tests as frame server for HCenc.
Most tests finished OK but the most basic test failed: Avisource input only.
Frames seem to have a wrong pitch.

Source is RGB in an AVI container.
Probably I'm doing something stupid because if this is a bug it should have been reported earlier I guess.

Used script:
s = AVISource("part2.avi")
s = ConvertToYV12(s)
return(s)

Source can be found here (http://hank315.nl/files/part2.7z).


BTW, Avisynth 2.6.a5 and 2.5.8 handled the source OK.
Is it correct frame->GetPitch is mod32 in Avisynth+ ?

I wish everybody who reports a bug would attach both a small clip and script like you. It just makes things so much easier. Thanks for the report. Looking into the probem at this instant.

[ultim]

Is there any list or Readme about avs+ functions?
I don't know any avs+ functions.

Not yet. After ironing out the MT stuff, I will work on updating the docs.

[mastrboy]

Any chance Avisynth+ could add a file extension bool parameter to the function ScriptFile() ?
Example to show use case:

episode_name = ScriptFile(show_extension=false)
FFVideoSource(episode_name+".avi")
TFM(output=episode_name+"-tfm.log")

[TurboPascal7]

Any chance Avisynth+ could add a file extension bool parameter to the function ScriptFile() ?
Example to show use case:

episode_name = ScriptFile(show_extension=false)
FFVideoSource(episode_name+".avi")
TFM(output=episode_name+"-tfm.log")

Can't you just write an overload with that parameter and remove the extension using existing string functions? What's the point?

[mastrboy]

If I had that knowledge I wouldn't have requested the feature ;)

Could you point me in the right direction for doing so?

[TurboPascal7]

If I had that knowledge I wouldn't have requested the feature ;)

Could you point me in the right direction for doing so?

function scriptfile(bool show_extension) {
actual = scriptfile()
ext_position = actual.revstr().findstr(".")
without_ext = actual.leftstr(actual.strlen() - ext_position)
return show_extension ? actual : without_ext
}
The only downside is that the parameter is not named because you still need a way to call internal avisynth function inside this wrapper. I'm not sure how you can work around that, other than changing the name of the wrapper function.

EDIT: here's a "workaround".
function scriptfile(bool "show_extension") {
show_extension = default(show_extension, true)
path = scriptname()
with_ext = path.RightStr(path.strlen() - scriptdir().strlen() - 1)
ext_position = with_ext.revstr().findstr(".")
without_ext = with_ext.leftstr(with_ext.strlen() - ext_position)
return show_extension ? with_ext : without_ext
}

[mastrboy]

That was fast.

Working perfectly also, I just renamed the function to "_ScriptFile".

Thank you :)

[ultim]

mpeg2source doesn't seem to work with avs+ mt on. I have a 1080p mpeg2 video which I indexed with dgindex, and trying to test with mt on, it gave me a green screen onload with avspmod, and when I try seek, the program just hangs. All three mt mode will hang.


SetFilterMTMode("MPEG2Source", 2)
MPEG2Source("sample.d2v", cpu=0)
Prefetch(4)


Please provide a sample clip.

[lansing]

I had this problem several times recently (using MT r1689) with scripts working perfectly with the vanilla Avisynth but failing to allocate frames in Avs+. Increasing the SetMemoryMax value is generally enough to make them work, but it also increases the overall memory usage, and you might end up closer to the fatal 4 GB barrier for a 32-bit process.


It's getting so frustrated for me with this issue, to a point that it's just literally unusable. When I try to encode a two hour long 480p video, after 30% in the process, it's telling me not enough memory. And when I try to mount the script through avfs to load in premiere, after 20 seeks in timeline, the program will exit by itself because of low in memory. I set setmemorymax to 3000 and it has no effect.

[innocenat]

There is a memory leak problem that just get fixed in Overlay filter in all MT built prior to last Monday. If you script doesnt use overlay can you post sample script?

[lansing]

There is a memory leak problem that just get fixed in Overlay filter in all MT built prior to last Monday. If you script doesnt use overlay can you post sample script?

the latest avs+ version I have is r1689. All my scripts contain qtgmc.

[ultim]

the latest avs+ version I have is r1689. All my scripts contain qtgmc.

It also has been discovered that in some cases the MT protection is not correctly applied to all filters. This is also the source of multiple problems reported here on the forums, like the issue with DSS+AudioDub, or with Mpeg2Source(1080i). Theoretically it can also cause leaks in filters.

A fix for this is on the way, but it may not be the cause for you at all. To make sure your leak gets fixed in the next public build, please post your script, and the format+resolution of your video (or even better, a short sample clip).

[lansing]

It also has been discovered that in some cases the MT protection is not correctly applied to all filters. This is also the source of multiple problems reported here on the forums, like the issue with DSS+AudioDub, or with Mpeg2Source(1080i). Theoretically it can also cause leaks in filters.

A fix for this is on the way, but it may not be the cause for you at all. To make sure your leak gets fixed in the next public build, please post your script, and the format+resolution of your video (or even better, a short sample clip).

This is the script I used with mounting. I don't have MT on. The video format is mpg, and resolution is 720x570.


qtgmc(preset="fast")

deblock_qed(quant1=50, quant2=26)
Crop(0, 0, -0, -6)


I loaded the video into premiere and opened task manager to keep track of the memory usage. Every time I seek, the memory usage of both premiere and Pismo file mount audit went up. In about 20 seeks, the mounting software would went over 3G and premiere over 4G, and eventually ran out of memory. I tested the same script with SEt's 2.6mt, the prior never go over 600MB and premiere never go over 2GB.

[Evil_Burrito]

woah woah woah, lansing, are you running that script into premier? Frameserving to an full editing application is supposed to only include source filters. Yes you "can" do it, but it is highly unrecommended (especially with heavy filters like qtgmc).

[lansing]

woah woah woah, lansing, are you running that script into premier? Frameserving to an full editing application is supposed to only include source filters. Yes you "can" do it, but it is highly unrecommended (especially with heavy filters like qtgmc).

my script wasn't "that" heavy compare to mctd, and I'm using preset=fast, and my resolution wasn't 1080. And I ran it with no problem using avs 2.6mt.

[ultim]

woah woah woah, lansing, are you running that script into premier? Frameserving to an full editing application is supposed to only include source filters. Yes you "can" do it, but it is highly unrecommended (especially with heavy filters like qtgmc).

I see no reason why frameserving to a "full editing application" like Premier shouldn't work reliably. So I still consider lansing's report a valid bug report and I will look into it. Right now I suspect it is not a leak, but some weird cache-behaviour which should be fixed, but this is just a guess right now.

[Boulder]

I'm going to hop on from Avisynth MT (SEt's latest v2.6 build) to Avisynth+ just for some testing. Are there going to be any expected difficulties that I definitely should be aware of or can I simply install it and start fiddling on things?

[ultim]

I'm going to hop on from Avisynth MT (SEt's latest v2.6 build) to Avisynth+ just for some testing. Are there going to be any expected difficulties that I definitely should be aware of or can I simply install it and start fiddling on things?

This bug (http://forum.doom9.org/showpost.php?p=1672010&postcount=678) makes it hard to tell different issues apart from each other. For this reason I would suggest you wait for the next public build, which will have not only this but also other important fixes in place, some already corrected in the repository.

[aegisofrime]

It also has been discovered that in some cases the MT protection is not correctly applied to all filters. This is also the source of multiple problems reported here on the forums, like the issue with DSS+AudioDub, or with Mpeg2Source(1080i). Theoretically it can also cause leaks in filters.

A fix for this is on the way, but it may not be the cause for you at all. To make sure your leak gets fixed in the next public build, please post your script, and the format+resolution of your video (or even better, a short sample clip).

Is this bug present in the last stable build, the one before MT was implemented? Because I have been finding that I have this script that always seem to crash in the same spot, and I guess it might be due to a leak.

Here's my script:


LoadPlugin("C:\DGDecIM\DGDecodeIM.dll")
DGsource("I:\Test\F1_T2_Video - .h264",engine=1)
AssumeTFF()
QTGMC(Preset="Very Slow")
Crop(0,0,0,-8)

I know that DGSourceIM is still in beta, but the script also crashes with the more mature DGAVCSource...

I would love to post my source, but it's a 20GB H264 from a Blu-Ray so that might be impractical...

[ultim]

Is this bug present in the last stable build, the one before MT was implemented?

No, it is not present in the stable build. That bug is strictly MT-related, and even in MT-builds only manifests if you have a Prefetch() call in your script.

I'll look at that bug of yours. It is also surely not due to the new caches, because the stable build still uses the old cache.

[Evil_Burrito]

I guess I stand semi-corrected. I did not mean to say it will be unstable, I just meant it will slow down your workflow while you are editing. Is this statement incorrect?

[real.finder]

hi :)

In order to avoid problems with fft3dgpu and Internal mt and other problems, it would be better to have mode 0, SetFilterMTMode("", none)

in mode 0 no mt mode will use, like works in regular avs

and for Prefetch, the 0 should be auto like regular avs mt, and make it default

thanks

[innocenat]

hi :)

In order to avoid problems with fft3dgpu and Internal mt and other problems, it would be better to have mode 0, SetFilterMTMode("", none)

in mode 0 no mt mode will use, like works in regular avs

and for Prefetch, the 0 should be auto like regular avs mt, and make it default

thanks

I am not sure what you mean. If you don't use Prefetch (or Prefetch(0)) everything will behave like regular non-multithreaded Avisynth.

If you are saying that there should be a mode where no MT mode is set for some filter in multithreaded filter chain, that would be impossible. The problem is that we are dealing with "filter chain" where its downstream filter can request frame from it however it wants. This is where MT mode come into play: it controls how the downstream filter request the frame from parent filter. Sadly, it still isn't perfect and we are still having problem.

[real.finder]

If you are saying that there should be a mode where no MT mode is set for some filter in multithreaded filter chain

yes, that what I mean, some thing like I said here (http://forum.doom9.org/showthread.php?p=1658255#post1658255) previously

that would be impossible

what about some thing like mp_pipeline but internal?

-----------


About my words for Prefetch, is meant for it's number of threads

[ultim]

hi :)

In order to avoid problems with fft3dgpu and Internal mt and other problems, it would be better to have mode 0, SetFilterMTMode("", none)

in mode 0 no mt mode will use, like works in regular avs

and for Prefetch, the 0 should be auto like regular avs mt, and make it default

thanks

I've had a similar idea. There would be 4th MT-mode, for example MT_DISABLED/MT_SINGLE_ONLY/MT_NO_MT (pick any naming you like), and if a filter uses this mode in a multi-threaded filter chain, the user would get an error that MT with that filter is not supported.

[ajp_anton]

I just realized that Overlay doesn't do its processing in RGB. Could this be "fixed"?

[Gavino]

I just realized that Overlay doesn't do its processing in RGB. Could this be "fixed"?
For RGB inputs, Layer() is preferable to Overlay() for most purposes. It's faster and uses less memory, but the range of features is not exactly the same, so it cannot do some things that Overlay() can.

[ajp_anton]

Why do we even have all those different functions? Overlay's "opacity" parameter could replace even Merge. Woudn't it be more practical to just have one function to do all of this?

[TurboPascal7]

Why do we even have all those different functions? Overlay's "opacity" parameter could replace even Merge. Woudn't it be more practical to just have one function to do all of this?
There are multiple ways of doing pretty much anything in avisynth, nothing really wrong with that.

I agree that the overlay/layer situation is a bit confusing, but without breaking compatibility with existing scripts, the best thing we could do is to unify the codebase and make one function a wrapper (possibly a script one) of another.

[ajp_anton]

Merge could also be implemented as a wrapper, unless you can make it faster by skipping all the extra stuff.
But yes, Overlay and Layer should be merged into one function with all the features and supported colorspaces of both, without doing unnecessary internal conversions.

[DeathAngelBR]

Well, hello.

I'm just wondering if a previous filter chain used for encoding with avisynth is going to work with avisynth+. I'm getting a bit more performance with the same settings in avs+, so it made me think that maybe the plugins/filters aren't working properly.

LoadPlugin("D:\Edição de video\MeGUI\tools\dgavcindex\DGAVCDecode.dll")
LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\removegrain\RemoveGrainSSE2.dll")
LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\removegrain\RepairSSE2.dll")
LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\removegrain\RSharpenSSE2.dll")
LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\outros\mt_masktools-26.dll")
LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\outros\mvtools2.dll")
LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\outros\AddGrainC.dll")
LoadPlugin("D:\Arquivos de programas\AviSynth 2.5\plugins\outros\dither.dll")
Import("D:\Arquivos de programas\AviSynth 2.5\plugins\outros\dither.avs")

video_ep04 = AVCSource("I:\BDMV Symphogear G Vol. 2\BDMV\STREAM\00004.dga")
video_ep05preview = AVCSource("I:\BDMV Symphogear G Vol. 2\BDMV\STREAM\00013.dga")

video_ep04 ++ video_ep05preview

addborders(0,4,0,4)
super = MSuper(pel=2, sharp=1)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4,mt=true)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4,mt=true)
MDegrain1(super, backward_vec1,forward_vec1,thSAD=64)
crop(0,4,0,-4,align=true)
dither_convert_8_to_16().dither_resize16(1280,720).smoothgrad().gradfun3(lsb_in=true,lsb=true,smode=2,mask=3).dither_out()

[ajp_anton]

Oh, and call me retarded, but where do I get revisions newer than r1576?
At least in that version, Layer completely ignores the overlay clip's alpha and assumes it's zero everywhere.
m = colorbars
c = blankclip(m,color=$808080)
o = blankclip(m,color=$ff0000)

o = mask(o,m)

layer(c,o)
#o.showalpha #to see that the mask is indeed there
Overlay red on top of grey with the colorbars greyscale as mask. Works in 2.6.

[CarlPig]

Oh, and call me retarded, but where do I get revisions newer than r1576?
At least in that version, Layer completely ignores the overlay clip's alpha and assumes it's zero everywhere.
m = colorbars
c = blankclip(m,color=$808080)
o = blankclip(m,color=$ff0000)

o = mask(o,m)

layer(c,o)
#o.showaplha #to see that the mask is indeed there
Overlay red on top of grey with the colorbars greyscale as mask. Works in 2.6.

I think this is the newest release: http://forum.doom9.org/showthread.php?p=1666364#post1666364

[ajp_anton]

Thanks.
Nope, Layer doesn't work there either. This is the reason I used Overlay in the first place, couldn't figure out how to get Layer to work so I switched. Turns out the fault wasn't mine =).