Avisynth+

[ryrynz]

Running Avsmeter with prefetch enabled causes the benchmark to slow down considerably.


[General info]
Log file created with: AVSMeter 1.7.6 (AVS 2.6, x86)
Avisynth version: AviSynth+ 0.1 (r1689, x86)


[Clip info]
Number of frames: 1726
Length (hhh:mm:ss.ms): 000:01:11.989
Frame width: 704
Frame height: 480
Framerate: 23.976 (2500000/104271)
Interlaced: No
Colorspace: YV12
Audio channels: 2
Audio bits/sample: 16
Audio samples/sec: 48000
Audio samples: 3454656


[Runtime info]
Frames processed: 8 (0 - 7)
FPS (min | max | average): 0.017 | 237169 | 0.044
CPU usage (average): 6%
Thread count: 27
Physical Memory usage (peak): 90 MB
Virtual Memory usage (peak): 173 MB
Time (elapsed): 000:03:00.148


[Script]
SetFilterMTMode("", 2)
SetFilterMTMode("Directshowsource", 3)
Directshowsource("c:\1.mkv")
Deblock(20)
VagueDenoiser(threshold=1.0, nsteps=8, chromaT=0)
Hysteria(strength=0.2, highthresh=200)
Prefetch(4)


[Performance data]
Frame Frames/sec Time/frame(ms) CPU(%) Threads PhysMEM(MB) VirtMEM(MB)
0 0.017 60057.016993 0 32 82 168
1 0.017 60014.952892 0 28 88 171
2 171.206 5.840931 0 28 88 171
3 8.837 113.165406 12 28 90 173
4 33203.609 0.030117 12 28 90 173
5 237168.577 0.004216 12 28 90 173
6 83.888 11.920692 12 28 90 173
7 0.017 59944.863827 0 27 90 173


Even just having deblock as the only filter with the prefetch call causes it to lag too, so it appears directly related to the prefetch call.
This script using Avisynth 2.6MT finishes in 33 seconds, avs+ without the prefetch call finishes it in 40 seconds.

[TurboPascal7]

Looks like it breaks because of the SetFilterMTMode("", 2) line. SetFilterMTMode("audiodub",3) should fix it. Apparently AudioDub (called by dss internally) has issues with MT mode 2 which you try to apply to it by default.
And I still believe this way of setting the default MT mode should be removed. Brings nothings but problems.


Should it be better to detect if MT mode is enabled ?
If someone use Avisynth+ without using multi-threading, i think internal multi-threading should be kept.
In theory - yes. But you have to use IScriptEnviroment2 to get number of threads and it's strongly discouraged right now.

The most optimal way from performance point of view would be providing a wrapper function around the plugin which would set number of threads to 1 and pass all other parameters unchanged right to the plugin. Something like:
function awesome_filter(clip c, int "thresh") {
awesome_filter(c, thresh, threads=1)
}
But this is again far from optimal because it's not currently possible to get number of threads in the script (it's not known at "compile" time) so you can't check if you're actually running MT in this function. But at least the user can comment this wrapper out if he wants to re-enable internal threading.

[Gavino]

Apparently AudioDub (called by dss internally) has issues with MT mode 2
That's strange, since AudioDub() doesn't do any real work of its own - it just redirects video and audio requests (GetFrame() and GetAudio()) to the appropriate input clip.

[aegisofrime]

I'm getting a few instances whereby my script just stops suddenly. It doesn't crash, the encoding process just stops. Perhaps signs of a deadlock?

Here's my script:


SetFilterMTMode("QTGMC",2)
SetFilterMTMode("FFVideoSource",2)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("I:\Temp\Test.mkv", fpsnum=24000, fpsden=1001, threads=1)
Dither_convert_8_to_16()
Dither_y_gamma_to_linear()
Dither_resize16(1280,720)
Dither_y_linear_to_gamma()
DitherPost()
QTGMC(Preset="Slow",InputType=1)
InterFrame(Cores=1,GPU=True)
PreFetch(3)


I'm also seeing the same thing when QTGMC'ing interlaced DVD content. I'm using Vit's modded Masktools and RGTools in place of RemoveGrain. Is there some logging mode I can invoke to help diagnose this problem?

[Groucho2004]

[B]SetFilterMTMode("QTGMC",2)
SetFilterMTMode("FFVideoSource",2)

You really should read ultim's notes (http://forum.doom9.org/showthread.php?p=1666371#post1666371) on how to use MT.
FFVideoSource should have Mode 3. I also doubt that you can set a mode for an entire script that uses a whole bunch of filters (QTGMC) which might each need to be treated differently.

[aegisofrime]

You really should read ultim's notes (http://forum.doom9.org/showthread.php?p=1666371#post1666371) on how to use MT.
FFVideoSource should have Mode 3. I also doubt that you can set a mode for an entire script that uses a whole bunch of filters (QTGMC) which might each need to be treated differently.

Thanks, I guess I missed the part about FFVideoSource. I guess I will also need to do some trial and error for the individual filters in QTGMC?

[lansing]

can someone put the mt version on another storage site? I can't download it from mega, when I try to download it as a zip, it always stuck at 17%.

[Groucho2004]

I guess I will also need to do some trial and error for the individual filters in QTGMC?
Yes, although here (https://pad.riseup.net/p/avs_plus_mt_modes) is already some info.

[ultim]

You cannot set the MT mode on script function calls, only on binary filters. So to make QTGMC work, all filters that it uses internally need their MT mode set. I did a basic test though when the the current test build was published, and QTGMC worked fine with a single SetFilterMTMode("", 2) call at the beginning and default arguments, so that is a start. But keep in mind that non-default arguments can easily require more complex MT-mode settings.

Anyway, thanks for all the testing. A few more days and I will begin hacking around it at large again. I am also thinking it might be very useful to have a logging framework in place (and maybe start with that), it could provide useful information about MT mode settings or other warnings to script writers. There is definetely a place to improve on the performance of the current version, and be assured that I will look at that in detail, as well as the issues that have been posted.

[TurboPascal7]

can someone put the mt version on another storage site? I can't download it from mega, when I try to download it as a zip, it always stuck at 17%.

This should do (http://forum.doom9.org/showthread.php?p=1666512#post1666512).

[lansing]

I did a simple test with mpeg2source, the prefetch() switch doesn't seem to do anything. Whether i put it there, prefetch(1) for single thread or prefetch(x), mt is always on.

[TurboPascal7]

I did a simple test with mpeg2source, the prefetch() switch doesn't seem to do anything. Whether i put it there, prefetch(1) for single thread or prefetch(x), mt is always on.

Please do post your full script. Also the best way of running a script singlethreaded is not including a prefetch call at all.

[lansing]

SetFilterMTMode("MPEG2Source",3)
MPEG2Source("sample.d2v", cpu=0)


Even when I took out the setfiltermtmode line, it still ran on mt. Here's the log from avsmeter:


AVSMeter 1.7.6 (AVS 2.6, x86) by Groucho2004
AviSynth+ 0.1 (r1689, x86)

Number of frames: 36853
Length (hhh:mm:ss.ms): 000:20:29.662
Frame width: 720
Frame height: 480
Framerate: 29.970 (30000/1001)
Interlaced: No
Colorspace: YV12

Frames processed: 6180 (0 - 6179)
FPS (min | max | average): 248.7 | 340.6 | 295.5
CPU usage (average): 12%
Thread count: 13
Physical Memory usage (peak): 35 MB
Virtual Memory usage (peak): 69 MB
Time (elapsed): 000:00:20.915

Press any key to exit...

[TurboPascal7]

The fact that you see more threads doesn't mean it's running MT. It's a minor implementation detail which might change in the future or it might not.
You can see that your CPU load is still locked at 12% which means one running thread on a 8-threads system.

[lansing]

No, it's running at 12% cpu because that's the max speed mpeg2source can run in my machine on multithread. If I ran the same vob file with ffvideosource, it would clearly show that mt is on because it would be a lot faster.

ffvideosource("sample.vob", fpsnum=30000, fpsden=1001)


AVSMeter 1.7.6 (AVS 2.6, x86) by Groucho2004
AviSynth+ 0.1 (r1689, x86)

Number of frames: 36849
Length (hhh:mm:ss.ms): 000:20:29.528
Frame width: 720
Frame height: 480
Framerate: 29.970 (30000/1001)
Interlaced: No
Colorspace: YV12

Frames processed: 36849 (0 - 36848)
FPS (min | max | average): 1242 | 1818 | 1660
CPU usage (average): 65%
Thread count: 30
Physical Memory usage (peak): 52 MB
Virtual Memory usage (peak): 68 MB
Time (elapsed): 000:00:22.202

[TurboPascal7]

Yeah because ffvideosource has internal mulithreading. It even has threads parameter which you can set to one.
There is no spoon.

[lansing]

Yeah because ffvideosource has internal mulithreading. It even has threads parameter which you can set to one.
There is no spoon.

You are right. I tried ran it with tnlmeans and took out the prefetch call, then it always ran at 12% cpu. When I change it to prefetch(8), it ran at 99%.

[ryrynz]

Any ideas on what caused my slowdown with avsmeter? Can it be reproduced?

[TurboPascal7]

Any ideas on what caused my slowdown with avsmeter? Can it be reproduced?
Did you try what I posted (http://forum.doom9.org/showthread.php?p=1667851#post1667851)? First two lines are about your directshowsource problem.

[ryrynz]

That's it. Wow. Avs+ did in 3 seconds what 2.6MT took 30 seconds to do..
Can audiodub be made mtmode 2 compatible?

[ultim]

That's it. Wow. Avs+ did in 3 seconds what 2.6MT took 30 seconds to do..
Can audiodub be made mtmode 2 compatible?

Wut? Tbh that looks too good to be true. All frames delivered with correct output?

[Groucho2004]

Wut?
That's what I thought, too. I'd like to see the log.

[ryrynz]

Actually forgot to edit the script back to it's original state.. it finished in 10 seconds.

http://codepaste.net/krm7oy

[Groucho2004]

Actually forgot to edit the script back to it's original state.. it finished in 10 seconds.

http://codepaste.net/krm7oy
So, you get 160 fps with AVS+ compared to 50 fps with SEt's MT Avisynth? And a fraction of the memory usage? Very nice.

[Seedmanc]

Neither AvsPmod nor AVSmeter seem to work with AVS+ for me, both just hang up whenever I try to open a script, even a simple "version()" call. Have to use Virtualdub again.

[Groucho2004]

Neither AvsPmod nor AVSmeter seem to work with AVS+ for me, both just hang up whenever I try to open a script, even a simple "version()" call. Have to use Virtualdub again.
Elaborate on "hang up". No error message?

[TurboPascal7]

Dear google translate users, please, get out of the MT modes pad.

[ryrynz]

So, you get 160 fps with AVS+ compared to 50 fps with SEt's MT Avisynth? And a fraction of the memory usage? Very nice.

Could drop memory usage down on 2.6MT, it's hard to tell what value you can use setmemorymax at for it to be stable.. but yes, a big difference here. Makes me wonder if 2.6MT is being benchmarked correctly, Avs+ is showing an extra 7 threads.

[TurboPascal7]

Avs+ creates two thread pools - one for prefetching threads (main pool) and one for user threads - avstp replacement allowing for more efficient internal threading implementation in plugins that cannot run with frame-level threading. So avs+ having more threads is hardly surprising.
That said, amount of threads right now is a bit silly. As I see it, with prefetch(4) it should be around 1 (main) + 3 (prefetch threads so 4 in total with main) + 4 (second thread pool) = 8, and not 20 or so created right now. Of course it hardly matters since most threads are idling, but should probably get fixed as mt becomes more stable.

[Seedmanc]

Groucho2004, well, I left both overnight trying to open a script and now I see both the same way I left them. I think I enabled logging in AVSmeter, but I don't see any logs in the folder. Meter remained at "AVSMeter 1.7.6 (AVS 2.6, x86) by Groucho2004" line in the console window.

[Groucho2004]

Groucho2004, well, I left both overnight trying to open a script and now I see both the same way I left them. I think I enabled logging in AVSmeter, but I don't see any logs in the folder. Meter remained at "AVSMeter 1.7.6 (AVS 2.6, x86) by Groucho2004" line in the console window.
You don't even see the "Analysing script, please wait..." line? Post your script.

[Seedmanc]

It looks like the problem was in "avsfilternet.dll" being in my plugins folder, now that I removed it it seems to work fine. It wasn't a problem with 2.6 though.

[tormento]

Some testing done this afternoon with 1080P material.

The following script works ok:

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,plane=0,chroma=false,lsb=true,mode=6)
Prefetch(3)

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.

[lansing]

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)

[udobroemme]

I think it was mentioned before... :)
For source filters you have to use
SetFilterMTMode("MPEG2Source", 3)

[lansing]

After a few more tests, I figure setting prefetch to 1 core will work, anything more than 1 will cause avsmeter to hang. And it doesn't matter which mode I use, all three will work if I call prefetch(1).

[Zep]

After a few more tests, I figure setting prefetch to 1 core will work, anything more than 1 will cause avsmeter to hang. And it doesn't matter which mode I use, all three will work if I call prefetch(1).

the question then, are

no prefetch in the script
prefetch(0)
prefetch(1)

truly equivalent? If so that should be why all modes worked.

yes I'm curious lol

[innocenat]

the question then, are

no prefetch in the script
prefetch(0)
prefetch(1)

truly equivalent? If so that should be why all modes worked.

yes I'm curious lol

No prefetch is technically Prefetch(0). Prefetch(1) is currently equivalent, but it is not guaranteed.

Prefetch itself predicts what frame will be requested next and fetch that frame in advance (in available thread). Prefetch(0) means to not use prefetching. Prefetch(1) will create a thread pool of one thread and do prefetching solely on that thread. Thus there is no guarantee that Prefetch(1) will request frame from its upstream filter in same order as it is requested (but it is currently this way)

[pinterf]

Tested AviSynth+ 0.1 (r1689, x86) mt for my 8mm film restoring project, while experimenting with Dither package, 10 bit x264 output, etc.

This film restoring script included Depan, RemoveDirtMC, MDegrain2, Crop16, Resize16 and converting between 8 bit and 16 bit stacked format and other functions from Dither Package.

SET's 2013.09.28 MT version was OK with SetMTMode(2). 95% CPU usage by AvsMeter.

So I generally enabled MT_MULTI_INSTANCE (except AviSource) but did not work. Tried to test MT modes but got no consistent results.
Finally turned out that either Dither_Out()/DitherPost() or Dither_Resize16() should be MT_SERIALIZED when MDeGrain2 used. When MDegrain2 was not used, even MT_NICE_FILTER worked for them. MDegrain2 comes from the modified mvtools2 package came with Dither tools.

Narrowed down the problem for this script.

For working version change comment/uncomment these lines: SetFilterMTMode("Dither_Resize16"...


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

# AVS+ version
SetFilterMTMode("", MT_MULTI_INSTANCE)
SetFilterMtMode("AVISource", MT_SERIALIZED)

#########################################
# External filters (guessed, might not be very stable)
##################################
#SetFilterMTMode("DitherPost", MT_SERIALIZED)
SetFilterMTMode("DitherPost", MT_NICE_FILTER)
SetFilterMTMode("Dither_Convert_8_to_16", MT_MULTI_INSTANCE)

# resize16 + crop16 are working even MT_NICE_FILTER in this sample
# when commenting out MDegrain2

#SetFilterMTMode("Dither_Resize16", MT_SERIALIZED) # when MDegrain2 used
SetFilterMTMode("Dither_Resize16", MT_MULTI_INSTANCE) # Freeze when MDegrain2 in clip

SetFilterMTMode("Dither_Crop16", MT_MULTI_INSTANCE)
SetFilterMTMode("Dither_quantize", MT_NICE_FILTER)
SetFilterMTMode("Dither_Out", MT_NICE_FILTER)
SetFilterMTMode("MDegrain2", MT_MULTI_INSTANCE)

SetFilterMTMode("MAnalyse", MT_MULTI_INSTANCE)
SetFilterMTMode("MRecalculate", MT_MULTI_INSTANCE)
SetFilterMTMode("MSuper", MT_MULTI_INSTANCE)

# Either Dither_Out or Dither_Resize16 should be MT_SERIALIZED when MDeGrain2 used
# otherwise avisynth+ hangs silently

#Load plugins explicitly
#-----------------------
DLLPath="..\8mmDLLs\"
#Loadplugin(DLLPath+"mt_masktools-26.dll") #Version 2.0.48.0 2012.04.02 needed for Dither_ package Access Viola on AVS+
Loadplugin(DLLPath+"mt_masktools-25.dll") #Version 2.0.48.0 2012.04.02 needed for Dither_ package
Loadplugin(DLLPath+"dither.dll") #Version ????? 2013.10.26
Import(DLLPath+"dither.avsi")
LoadPlugin(DLLPath + "mvtools2.dll") # Version 2.6.0.5 MSuper, MDegrain2, etc.. (2012.07.17 Dither 1.24 package modified version)
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)

#MDegrain2 from the modified Dither package version mvtools2
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)

[Zep]

No prefetch is technically Prefetch(0). Prefetch(1) is currently equivalent, but it is not guaranteed.

Prefetch itself predicts what frame will be requested next and fetch that frame in advance (in available thread). Prefetch(0) means to not use prefetching. Prefetch(1) will create a thread pool of one thread and do prefetching solely on that thread. Thus there is no guarantee that Prefetch(1) will request frame from its upstream filter in same order as it is requested (but it is currently this way)

mode 1 working then seems a bit odd in Prefetch(1) with lansings filter choice. Was mode 1 really being utilized?

[TurboPascal7]

Note to all people having any kind of issues with mt build: first of all, try removing SetFilterMTMode("", MT_MULTI_INSTANCE) from your script. I have absolutely no idea why this was introduced in the first place since it only creates problems. Yes, this will cripple performance but no one promised you it'll be easy.

Second - setting any MT mode on script functions does nothing. For example, SetFilterMTMode("Dither_Crop16", MT_MULTI_INSTANCE) doesn't change anything. You can put any other MT mode there and it will still work they way it works by default. Only plugin functions matter.

Third - situation where one plugin works with mode 1 when used before filter X and only with mode 2 when X is not present is pretty much impossible (assuming there are no bugs in the core of course :)). MT mode is a property of a filter and it doesn't depend on where it's used, only on filter implementation and input parameters (unless the filter is completely broken). I understand this is not helping much and thank you for posting scripts with this kind of problems, but most likely it means that MT mode of one of the filters was not "guessed" right. Hopefully we can get authors of some plugins who are still alive (dither for instance) to supply correct MT modes for every function in their plugins, either as a registration routine in the plugin itself, or SetFilterMtMode line. If we can't, well... we'll be guessing.

EDIT: as innocenat pointed out on IRC, it's actually possible to have filters changing their behavior if they're called before a filter with MT mode 3. All filters are getting serialized and any MT mode you're applying to them should not matter. This is an implementation detail though and you should not rely on it in any way since it might get changed without notice.

Now, to Prefetch(1)/Prefetch(0) issue. As ultim explained (no one bothered to read the full MT implementation tbh because it feels a bit (over)complicated), the number that you supply to prefetch is the number of prefetching threads. So in theory Prefetch(1) should give you two threads - one main thread and one prefetching thread. Prefetch(0) should disable any multithreading.

As usual, practice doesn't match theory very well and Prefetch(1) actually gives you one working thread (dunno if it's the main or the created one). Yes, this is a bug and it most likely will be fixed.

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.

In short - yes, currently Prefetch(1) and Prefetch(0) are almost equivalent. In the future one of these might error out, or this behavior will be kept (probably more reasonable).

[pinterf]

TurboPascal7, thank you the script function vs mt mode note, although I knew it, did not check which Dither function was implemented in script.

Luckily I have cought an error message displayed for a few tenth of seconds (then made a screenshot video)
"Dither_resize16: resizing ratio too low or kernel support too high." In MT_SERIALIZED mode it does not occur. (v1.24)

[mark0077]

Guys maybe this is a stupid question, but has someone (or is it even possible) to use this with SVP? I have been trying with no luck to replace my SetMTMode calls with SetFilterMTMode calls towards SVP functions. Maybe its not even possible unless SVP add support in their dlls?

[hank315]

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+ ?

[TurboPascal7]

Is it correct frame->GetPitch is mod32 in Avisynth+ ?
Most of the times - yes. But you still can get unaligned input after crop(align=false) for example.

[Zathor]

ClearAutoloadDirs()
AddAutoloadDir("C:\Program Files\MeGUI\tools\avs\plugins")
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\NicAudio.dll")
RaWavSource("E:\audio.wav")
SSRC((AudioRate()*25)/24).AssumeSampleRate(AudioRate()).TimeStretch(pitch=Float((AudioRate()*25)/24)*100.0/Float(AudioRate()))
return last
"An error occurred: Input audio sample format to SSRC must be float."

Seems portable version is AviSynth+ (ClearAutoloadDirs(), AddAutoloadDir()), and I think have a new version of SSRC but maybe without the automatic conversion of input data type than AviSynth 2.5.8 have.
When source was decoded from AC3, DTS, etc. with NicAudio or BassAudio the audio samples are float, but from losless sources the audio samples are int, and SSRC from AviSynth+ show the Error.

It seems that the SSRC filter in AviSynth+ cannot accept int audio while the AviSynth filter does. Reason seems to be that the automatic conversion mentioned here (http://avisynth.nl/index.php/ConvertAudio) seems to be not working. Is that a missing feature/intended or a bug?

[Zep]

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.

In short - yes, currently Prefetch(1) and Prefetch(0) are almost equivalent. In the future one of these might error out, or this behavior will be kept (probably more reasonable).

Thanks turboPascal your post was exactly the info i was looking for from a high level users eyes. For me I don't need the super low level details but I do want to know enough so i can tweak performance or at least a good guess as where to start/try.

thanks

[qyot27]

It seems that the SSRC filter in AviSynth+ cannot accept int audio while the AviSynth filter does. Reason seems to be that the automatic conversion mentioned here (http://avisynth.nl/index.php/ConvertAudio) seems to be not working. Is that a missing feature/intended or a bug?
It's by design:
https://github.com/AviSynth/AviSynthPlus/commit/d40f4a2e833998199dec0e0e4737cf69c4607b6c


There was also a forum post that mentioned it or explained the rationale (that it shouldn't do that kind of conversion without the user's knowledge), but I can't find it right now.

[Zathor]

Thanks, I have added ConvertAudioToFloat() to the script logic.

[zerowalker]

Here is a Bug Report, a Script that fails for no reason while it works on AVS 2.6 according to another user.

http://forum.doom9.org/showthread.php?p=1670117#post1670117

Hope that helps.