Avisynth+

[videoh]

If your source is DVB AVC TS then you first need something to fix av sync, in the last release I made demuxing with DGAVCIndex the default method to demux AVC TS, this was experimental and it was a failure since it failed to keep av sync for a simple recording. The next release again will use dsmux to convert AVC TS to MKV while fixing av sync. This means your source is mkv which means you can use LWLibavVideoSource or DGSource (DGDecNV) as alternative to FFVideoSource, you can make this default at Tools > Settings > Source Filters > default > LWLibavVideoSource

FFVideoSource and LWLibavVideoSource are both based on ffmpeg so you might see the same problems, DGSource might also cause problems and maybe decoding to a loss less codec is a alternative, I've seen people do it before but don't know exactly why. Either way dealing with 1080p or even 4K will push things to the limit. You are misusing the DG tools and then claiming they are not working! All the DG tools demux with the required delay adjustment in the audio file name. You must adjust for that delay in your script. If you can demonstrate a real problem when using the tools as intended, then I will be happy to look into it.

[StainlessS]

Stax

### Filled in by DGIndex when using as DGIndex Template
VideoFileName ="__vid__"
AudioFileName =("__aud__")
AudioDelay =Value("__del__")

Dont off hand know if DGxxxx command line allows for template, but above via DGIndex works great (as well as delay in filename as VH suggests).

[stax76]

You are misusing the DG tools and then claiming they are not working! All the DG tools demux with the required delay adjustment in the audio file name. You must adjust for that delay in your script. If you can demonstrate a real problem when using the tools as intended, then I will be happy to look into it.

I double checked it and the file is very simple, I have a very fast connection and could easily upload it but DGAVCIndex is discontinued, right? Would you be willing to fix it? If you want I can also try with DGDecNV and tell you if it works better.

[videoh]

You double-checked what? Please upload your file so I can test it. Thank you.

And you say DGSource() may also cause problems. What problems?

[stax76]

You double-checked what? Please upload your file so I can test it. Thank you.

I tested it two times, it's really not working, here is the log:

http://pastebin.com/TepyAc3G

What's StaxRip does here is just muxing without any encoding and as you can see the delay is accounted in the mkvmerge command line.

I can upload the file no problem but for what do you need it? DGAVCDec is discontinued, right?

And you say DGSource() may also cause problems. What problems?

Problems with QTGMC, so far I'm only observing the topic and collect info.

[videoh]

Please upload the file. I need it to check your claim that one of my tools is failing. I also want to test it against DGDecNV and DGDecIM. Most of the code is the same. Sure, DGAVCDec may be faulty and won't be updated. But I need to check that my other tools are not affected the same way. I helped you with the progress reporting technology, can't you help me by uploading the file?

Problems with QTGMC, so far I'm only observing the topic and collect info. What problems with QTMC, and what is the connection to DGSource()? And if you are only observing and collecting info, why be in such a hurry to blame DGSource()? Why not list every tool used by QTGMC and say they may have problems?

[stax76]

Please upload the file. I need it to check your claim that one of my tools is failing. I also want to test it against DGDecNV and DGDecIM. Most of the code is the same. Sure, DGAVCDec may be faulty and won't be updated. But I need to check that my other tools are not affected the same way.

What problems with QTMC, and what is the connection to DGSource()? And if you are only observing and collecting info, why be in such a hurry to blame DGSource()? Why not list every tool used by QTGMC and say they may have problems?

Yes, it's async with DGDecNV as well but I'm not helping you if you be difficult like that all the time, I rather avoid mentioning DG tools and be super extra careful if I have to.

[videoh]

I think you are overreacting, but have it your way.

Have you tried reversing the sign on your --sync parameter? It may not work the same as DelayAudio(). I could troubleshoot it if I had your file. All DG tools users would potentially benefit.

Good luck with your projects, and if you ever want me to look into your issues, just let me know.

[l33tmeatwad]

...but I'm not helping you if you be difficult like that all the time...I hate to break it to you...but you're actually the one that's being difficult...if you want things fixed work with people or fix it yourself.

[StainlessS]

I hate to break it to you...but

That is how it seemed to me too.

[jpsdr]

I can upload the file no problem...
In that case just do it, videoh even asked for it. You've nothing to loose.

[stax76]

random DVB recording I recorded for testing purpose.

KabelBW, Germany, DVBViewer, ZDF HD, TS, AVC, MP2, 720p, 50fps

http://www.mediafire.com/download/wxi04urz0p1lte7/720p_-_AVC_-_MP2_2.0_-_ZDF_HD.ts

General

ID : 1079
Audio_Codec_List : MPEG-1 Audio layer 2
Audio_Language_List : German
Codec/String : MPEG-TS
FileSize/String4 : 676.7 MiB
Duration/String1 : 7mn 29s 961ms
OverallBitRate/String : 12.6 Mbps
FrameRate/String : 50.000 fps
FrameCount : 22481
StreamSize/String : 34.4 MiB (5%)
File_Created_Date_Local : 2012-02-05 14:35:16.103
File_Modified_Date_Local : 2010-09-27 11:07:12.806

Video

ID : 6110
Format_Profile : Main@L4
Codec/String : AVC
Duration/String1 : 7mn 29s 620ms
BitRate_Mode : VBR
BitRate/String : 11.7 Mbps
Width/String : 1 280 pixels
Height/String : 720 pixels
PixelAspectRatio : 1.000
DisplayAspectRatio/String : 16:9
FrameRate/String : 50.000 fps
FrameCount : 22481
Resolution/String : 8 bits
ScanType : Progressive
StreamSize/String : 629 MiB (93%)

Audio

ID : 6120
Format_Profile : Layer 2
Codec/String : MPEG-1 Audio layer 2
Duration/String1 : 7mn 29s 856ms
BitRate_Mode : CBR
BitRate/String : 256 Kbps
Channel(s)/String : 2 channels
SamplingRate/String : 48.0 KHz
FrameCount : 18744
Compression_Mode : Lossy
Video_Delay : -1053
StreamSize/String : 13.7 MiB (2%)
Language/String : German

Menu

ID : 6100
Codec/String : AVC / MPA1L2 / / / / /
Duration/String1 : 7mn 29s 961ms
Language/String : / German

[videoh]

Thank you. Investigating...

[videoh]

OK, I tested DGDecNV because you said that is not working for you also. I find that it is operating correctly as designed. To show this, I loaded your file and saved project. Then I made this script:

loadplugin("dgdecodenv.dll")
loadplugin("nicaudio.dll")
vid=dgsource("720p - AVC - MP2 2.0 - ZDF HD.dgi")
aud=nicmpg123source("720p - AVC - MP2 2.0 - ZDF HD PID 17e8 L2 2ch 48 256 DELAY -1444ms.mp2").delayaudio(-1.444)
audiodub(vid,aud)

Playing the script in VirtualDub, everything is in sync, showing that DGDecNV is operating correctly as designed.

I also did it by first demuxing the 264 ES using DGIndexNV and then did the above but starting with the demuxed file. The result was the same, ie., in sync.

Then I used mkvtoolnix to mux the 264 ES and the audio, specifying the delay adjustment with --sync. The result was out of sync. I also did a delay cut edit of the audio and then made the MKV again but without --sync. The result was again out of sync.

So the question is why are things out of sync in the MKV? The answer is that there are a lot of leading non-IDR/I frames before the first IDR/I (your stream was not cut at a GOP). DGDecNV is designed to replace those frames with copies of the first IDR/I frame, and the audio is demuxed starting from the beginning. But mkvtoolnix discards all those frames and that is what leads to async.

Every demuxer has to align the starts of the audio and video *as the demuxer sees things*. Other demuxers may discard the leading frames and start the audio demux later at the first I frame. DGDecNV, however, tries to retain all the frames, so it starts the audio demux much earlier.

If we had to assign "blame" anywhere, it is in the assumptions of your workflow, which are incorrect. By using DGDecNV demuxing you are committing to using a muxer that retains all the leading non-IDR/I frames, but the muxer you chose does not do so. For your workflow, a demuxer like eac3to would be suitable.

Conclusion: DGDecNV is operating correctly as designed. Your hybrid workflow makes incorrect assumptions, so DGDecNV demuxing is not suitable for your workflow, but it is not broken. I would respectfully ask you not to jump to conclusions and say some tool is a failure, before consulting with the developer. That is surely what you expect from staxrip users, isn't it?

[manolito]

Interesting source file...
I do not do many HD conversions (oldfashioned DVD guy), but opening HD sources happens frequently, so I played a little with this source:

First of all I ran the file through TSDoctor, but this had no influence at all for the sync issue. The processed file had a slightly shorter audio delay (1005ms instead of 1053ms), and it was significantly shorter than the original. But it did not solve the sync issues.

Trying a conversion to DVD I first opened the video with ffvideosource (audio through DirectShowSource). I had to use the old version 2.17 because all later versions do not run on my machine (SSE2 problem). Result: Terrible audio desync.


Next I used DSS2Mod for video (preroll = 15, otherwise default settings). LAVFilters 0.65 were used.

Result:
When the reported audio delay of 1053ms was corrected, the result was out of sync. But when I ignored the audio delay, I got a perfect conversion without any sync problems. (The TSDoctor processed file gave the same result).

This confirmed my previous experience with the DSS2Mod / LAVFilters combination. Whenever MediaInfo reports an audio delay greater than 100ms, just ignore it and get a perfect result.


Just for fun I then processed the file with the old StaxRip version 1.1.9.0. StaxRip automatically selected DirectShowSource as the source filter (LAVFilters were installed), and I got a resulting file which was in perfect sync.


Cheers
manolito

[videoh]

Thanks, manolito, for the input on this. You have underlined the point that tools must be combined in the right way, taking into account their specific designs and behavior. One can't assume that any combination of tools will do what one wants, and one can't call them broken because one makes an incorrect assumption about how they operate.

So the idea that staxrip can just allow free choice of source filters, etc., without regard to how they are combined is asking for trouble.

[manolito]

Thanks videoh for explaining how your source filters work differently than other source filters.

I noticed this whenever I converted a DVD (or MPEG2) source. AVStoDVD gives me a choice in these cases to either use DGIndex / DGDecode or to use DSS (or DSS2Mod or whatever). When I use DGIndex, I need to honor the reported audio delay even if it is very large. For DSS2Mod I always have to discard large delay values.

So far I had no explanation for this behavior, but now I do... :D


Cheers
manolito

[videoh]

An aside on why DGDecNV does things this way. Suppose you have a stream with a bunch of leading B frames. If you discard them, you have to discard audio too. But what if it's a song or a narration...you don't want to truncate the audio at the beginning. The philosophy is to deliver an output frame for all coded input frames. It just seems like the right thing to do if you want to claim frame accuracy. The user asks for frame N; he shouldn't have to adjust the number depending on how many leading B frames there are. Well, that's my take on things.

I suppose that is why CUVID and MSDK also deliver an output frame for all coded frames, regardless of frame type. That way there is also no need to coordinate with the audio. E.g., how could CUVID signal that is dropping some leading frames or not?

I had to jump through hoops when making DGAVCDec to work around the fact that libav was discarding leading B frames. That's one reason why I decided to stop using libav.

[qyot27]

Trying a conversion to DVD I first opened the video with ffvideosource (audio through DirectShowSource). I had to use the old version 2.17 because all later versions do not run on my machine (SSE2 problem). Result: Terrible audio desync.
Not that it would necessarily do anything to the desync issue, but the C-plugin builds are more lax about this (http://forum.doom9.org/showthread.php?p=1720384#post1720384).

[manolito]

Thanks qyot27 for this reminder, I do know this...

Doesn't help me though because I mainly use AVStoDVD for my encodes, and the LoadPlugin call for ffms2.dll is hard coded into the executable. Not much I can do about it except compiling my own version of AVStoDVD...


Cheers
manolito

[stax76]

the fps drop issue with MT seem to happen only with certain filters, I was successful with this:

DGDource
QTGMC
Prefetch
SelectEven

but as soon as I added crop after DGDource the fps drop issue was back, I tried HW cropping then and again fps drop was happening, unfortunately many popular scripts are not usable at the moment, makes me wonder if QTGMC works better with VapourSynth, adding basic support to StaxRip might be easy.

[chainik_svp]

Please update avisynth.h header accordingly to AVS 2.6 final release!
Restore GPL exemption.
;)

[innocenat]

@chainik_svp: https://github.com/AviSynth/AviSynthPlus/issues/62

[LigH]

Today I tried to play an AviSynth file with a fresh built ffplay, and it complains:

[avisynth @ 00000000030c6f80] AviSynth version is too old. Please upgrade to either AviSynth 2.6 >= RC1 or AviSynth+ >= r1718.

The homepage and the github releases only offer AviSynth+ r1576; so where do I get AviSynth+ r1718 or newer from?!

And on top, will AviSynth+ MT be continued?

[thescrapyard]

Here is the installer for r1779, I'm still hunting for r1825 or r1833

http://www.mediafire.com/download/wiwhhbtd3bcqcox/AviSynth%2B_v0.1.0_r1779.exe


Found it after a few more minutes of hunting and trawling through StaxRip forums topics as he uses AviSynth+ as well

http://www.mediafire.com/download/hvnjb8wy54ys7gl/AviSynth%2B_v0.1.0_r1825-MT.exe


Both links confimed working, as I've just downloaded both

[LigH]

:thanks: a lot!

Now ffplay works well; and by the way, this issue happened with a 64 bit ffplay, so no surprise it didn't work with AviSynth 2.60 final either ... which is 32-bit only :o

[thescrapyard]

This might help others, like me, that use AviSynth+ about development and appearing to have stalled and the current release state

Basically it hasn't stopped, more like idling and does get minor updates as and when needed with the main developer working on the core when he has time. Which apparently may be very little for 'side projects'

https://www.doom9.org/showthread.php?p=1719763#post1719763

[qyot27]

And on top, will AviSynth+ MT be continued?
There is no division there like there is for classic AviSynth; the MT branch has been the main branch of AviSynth+ for nearly a year and a half (the length is mostly because of the hiatus that was in there; we're currently in kind of another one after a rather busy March). MT is the Git HEAD branch.

In the event that 0.2 stable is released sometime soon, it will be MT capable (even if the 'stable' tag would mostly be referring to the single-threaded mode). Whenever that happens, the message in libavformat will get modified to reflect a point release rather than a development revision number.

For quick reference,
r1718 was the update against 2.6 RC1 (and technically would be r1723 or thereabouts if checked out from Git; some of the changes were uncommitted at the time I made that build)
r1825 is the current Git HEAD.
r1833/r1834 (which exists in a still-unmerged pull request) is the extremely-paltry update against RC2. RC3's changes were completely irrelevant to AviSynth+. r1834 adds the exception clause back to avisynth.h and is thus updated against 2.6.0 Final, but as the issue innocenat linked to shows, there's still some pondering about whether that's do-able with the changes already made to avsplus during the 2.6 alpha period.


ffplay isn't really a good way of previewing scripts, because it's more of a test bed for the FFmpeg libraries than a canonical media player. mpv is vastly preferable here. Someone might want to bug the VLC devs to expose AviSynth support through libavformat, since it currently doesn't (or didn't, at least the last time I checked).

[LigH]

Thank you for the summary.

Using ffplay was in fact rather a test if ffmpeg based tools can be used at all; but I will recommend mpv as alternative now, even though I don't always build it, it used to fail compiling often in the past.

[vcmohan]

on my lap top windows 8.1 64 bit quad core, installed from home page avisynth+. Compiled plugins in 64 bit mode using VC++ community edition 2013. With loadplugin("....") call get message unable to load. If I paste the plugin dll in avisynth64+ plugins folder, get a message of no such function. Earlier I had 2.6 and opted for upgrade. Both 32bit and 64bit check boxes were ticked. Regular 32 bit plugins compiled for avisynth2.6 are being loaded. In the installation log I see the avissynth.dll (almost an year older to avisynth2.6) is installed. I also see in the wow64bit folder also a avisynth.dll.
In the documentation I do not see any help for using setFilterMtMode or prefetch.Do I need to do any thing else to be able to load 64 bit plugins compiled using the recommended header file for avisynth+?

[LigH]

You'll have to call the AviSynth script directly from a 64 bit application to load 64 bit AviSynth+ to load 64 bit plugins.

Try it first with AVSMeter64.exe – when it passes the analysis and starts processing frames, it worked.

[Reel.Deel]

@vcmohan

You can also try 64-bit VirtualDub (http://www.videohelp.com/software/virtualdub). You might want to upgrade to the latest AviSynth+ (r1825) (http://avisynth.nl/index.php/AviSynth%2B#Latest_Release) also.

The documentation for SetFilterMTMode and Prefetch is here: http://avisynth.nl/index.php/AviSynth%2B#MT_Notes

[vcmohan]

@vcmohan
The documentation for SetFilterMTMode and Prefetch is here: http://avisynth.nl/index.php/AviSynth%2B#MT_Notes
Many thanks. I did not understand clearly the following.
Per-frame heap allocations should be avoided, because they can act as implicit synchronization points between threads.
Can I use in getFrame method say float * var = new float[vi.width*vi.height]; and at end of this getFrame method use a delete []var; ? Does this cause the implicit synchronization? If so what should I do to have a writable buffer in getFrame section?

[innocenat]

If you don't care about original Avisynth support, current Avisynth has IScriptEnv2.Allocate (just cast from your original IScriptEnv), which you should use with mode AVS_POOLED_ALLOC. But I don't know whether this solve the implicit synchronization, nor whether this API is stable. It is being used by internal filter though: https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/filters/resample.cpp#L755

[8-BaLL]

What is more stable/powerful at the moment AVS+ or AVS 2.6 final? Which one do you guys prefer atm?

[Groucho2004]

What is more stable/powerful at the moment AVS+ or AVS 2.6 final? Which one do you guys prefer atm?
You're going to get variety of opinions with this kind of question. I'd say use AVS 2.6 for serious work. The current AVS+ builds are really in Alpha stage and I've had problems with them, especially using complex scripts like QTGMC.

[stax76]

You're going to get variety of opinions with this kind of question. I'd say use AVS 2.6 for serious work. The current AVS+ builds are really in Alpha stage and I've had problems with them, especially using complex scripts like QTGMC.

MT is alpha I agree but single threaded works completely fine in my experience.

[Groucho2004]

MT is alpha I agree but single threaded works completely fine in my experience.
In my tests the 32 bit r1825 (have not tested 64 bit) slows down continuously with QTGMC, no matter if single threaded or multi threaded.
There is something odd with the memory management in the newer builds, they use much less memory than r1576 or 2.6 but it seems that this is exactly what causes the slowdown. Just a hunch.

[8-BaLL]

Alright thanks, I guess I will just keep using 2.6 then.

[vcmohan]

@vcmohan

You can also try 64-bit VirtualDub (http://www.videohelp.com/software/virtualdub). You might want to upgrade to the latest AviSynth+ (r1825) (http://avisynth.nl/index.php/AviSynth%2B#Latest_Release) also.

The documentation for SetFilterMTMode and Prefetch is here: http://avisynth.nl/index.php/AviSynth%2B#MT_Notes
I have virtualdub 64 bit version. With version() call I get a message AVISYNTH+ 0.1 (r1576 x64)
I thought home page installer puts the latest dll.
However with SetFilterMTMode("..", 1)
I get a message no function named setFilterMTMode
The script I am using is:
loadplugin("C:\TransPlugins\bin_64\HistogramAdjust\x64\Release\HistogramAdjust.dll")
#----------------------------------------

SetFilterMTMode("HistogramAdjust",1)
imagesource("c:\images\source1_z.jpg",end = 500)

converttoyV12()
HistogramAdjust(limit = 70)
prefetch(6)
what is the problem?

[foxyshadis]

Try a script with nothing but
Version()
and see what that gives.

[Groucho2004]

I have virtualdub 64 bit version. With version() call I get a message AVISYNTH+ 0.1 (r1576 x64)
I thought home page installer puts the latest dll.
However with SetFilterMTMode("..", 1)
I get a message no function named setFilterMTMode
The script I am using is:
loadplugin("C:\TransPlugins\bin_64\HistogramAdjust\x64\Release\HistogramAdjust.dll")
#----------------------------------------

SetFilterMTMode("HistogramAdjust",1)
imagesource("c:\images\source1_z.jpg",end = 500)

converttoyV12()
HistogramAdjust(limit = 70)
prefetch(6)
what is the problem?
The installer from avs-plus.net installs the latest stable (r1576) which does not support MT.
A link to the r1825 binaries is here (http://forum.doom9.org/showthread.php?p=1719768#post1719768).

[goorawin]

I have just started using the latest version Avisynth+ (r1825) and seems to be working reasonable well and quicker in some situations where 64bit can be used. Looks very promising, so great work by those who have developed it to this stage.
The version I have found to work really well for almost everything is 2.6 MT but it is only 32bit.
However although I can get many scripts that work in 2.6 MT to work in plus, I can not get the following script to work at all. So I'm hoping someone can help. I use this script a lot in batch encoding and it should allow VirtualDub 64 bit to be used for that.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("FFVideoSource", 3)
LoadVirtualDubPlugin ("C:\Virtual Dub\plugins32\Deshaker.vdf", "deshaker", preroll=0)Clip="D:\Batch Script Render\Iutput Files\Test.mts"
V1=FFVideoSource(Clip)
A1=FFAudioSource(Clip,track = -1)
AudioDub(V1, A1)#.AdvancedMultiTrim("0,-25")
ConvertToRGB32()
SCRIPT_1=Deshaker("19|1|30|4|1|0|1|0|640|480|1|2|1000|1000|1000|1000|4|1|4|2|8|30|300|4|C:\\Users\\Peter\\AppData\\Local\\Deshaker\\Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|8|8|3|8|0|0|30|30|0|0|1|0|1|1|0|10|1000|1|90|1|1|20|5000|100|20|1|0|ff00ff")
ForceProcess(SCRIPT_1)
SCRIPT_1 = 0
SCRIPT_2=ConvertToRGB32(matrix="Rec709").Deshaker("19|2|30|4|1|0|1|0|640|480|1|2|1000|1000|1000|1000|4|1|4|2|8|30|300|4|C:\\Users\\Peter\\AppData\\Local\\Deshaker\\Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|8|8|3|8|0|0|30|30|0|0|1|0|1|1|0|10|1000|1|90|1|1|20|5000|100|20|1|0|ff00ff")
\.ConvertToYUY2() # I can add other plugins here


return SCRIPT_2

Function ForceProcess(clip c) {
# Force process c clip
RT_DebugF("Starting Force process of clip") # EDIT: Output to DebugView (google)
GScript("""
for(i=0,c.FrameCount-1) {
RT_YankChain(c,i)
}
""")
}

This line SCRIPT_1=Deshaker .......... causes "system exception- access violation"

Any suggestion to get this to work in Avisynth + would be very much appreciated.
Thanks

[qyot27]

Does 64-bit VirtualDub load 64-bit plugins from plugins64? Because you're pointing to the Deshaker plugin in plugins32.

Also, GScript's extensions were integrated into AviSynth+; you can just use those features natively now.

[goorawin]

I am trying to use virtualdub 32bit to get it to work. I'm testing it on Avspmod, which only handles 32bit. I did try to load it direct into ffmpeg but that failed as well.
It is the first deshaker pass that fails to load.
I'll look at the Gscript issue later, but that shouldn't cause any of these issues.
I have also tried loading just the first pass which works in 2.6.
Thanks for your input

[bxyhxyh]

Deshaker plugin is not really compatible with MT avisynth. It is also internally multi-threaded. This maybe the case. Have you tried single threaded settings (if is there exist)?

[goorawin]

Well it may not be compatible with MT but I have been using it now for a year or more with 2.6 MT.
It took many days to set it up so it would work and it renders quicker than a single thread setup.
This is an example of the script I use.
SetMemoryMax(512)
Setmtmode(5,4)
LoadVirtualDubPlugin ("C:\Virtual Dub\plugins32\Deshaker.vdf", "deshaker", preroll=0)Clip="G:\Africa\Wilds\Final Edit\Part02\199.mts"
V1=avss_26_DSS2(Clip, fps = 50)
A1=FFAudioSource(Clip,track = -1)
AudioDub(V1, A1).AdvancedMultiTrim("0,-25")
Setmtmode(2)
SCRIPT_1=ConvertToRGB32(matrix="Rec709").Deshaker("19|1|30|4|1|0|1|0|640|480|1|2|1000|1000|1000|1000|4|1|4|2|8|30|300|4|C:\\Users\\Peter\\AppData\\Local\\Deshaker\\Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|8|8|3|8|0|0|30|30|0|0|1|0|1|1|0|10|1000|1|90|1|1|20|5000|100|20|1|0|ff00ff")
ForceProcess(SCRIPT_1)
SCRIPT_1 = 0
Setmtmode(2)
SCRIPT_2=ConvertToRGB32(matrix="Rec709").Deshaker("19|2|30|4|1|0|1|0|640|480|1|2|1000|1000|1000|1000|4|1|4|2|8|30|300|4|C:\\Users\\Peter\\AppData\\Local\\Deshaker\\Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|8|8|3|8|0|0|30|30|0|0|1|0|1|1|0|10|1000|1|90|1|1|20|5000|100|20|1|0|ff00ff")
\.ConvertToYV12()
\.MTClipEnhance(levels=245, gamma=1.05, WB=0.20, saturation=1.20, Hue1=-2,Hue2=1)

return SCRIPT_2

Function ForceProcess(clip c) {
# Force process c clip
RT_DebugF("Starting Force process of clip") # EDIT: Output to DebugView (google)
GScript("""
for(i=0,c.FrameCount-1) {
RT_YankChain(c,i)
}
""")
}

The MTClipEnhance also has a Setmtmode within it.
I would just like to be able to use it within Avisynth + . This would save the need for changing versions and hopefully we could get a further increase in rendering speed.

[goorawin]

I forgot to mention that yes I did try, as best as I could, a single threaded settings.

[RenderGuy2]

This may already be known and deemed unimportant as ffdshow is no longer being developed, but I have noticed that r1825 is not available to ffdshow rev4533 x64. Avisynth+ r1779 works as it should with ffdshow. Scripts added to ffdshow with r1825 simply have no effect.

[ianken]

Any idea when there will be a new release with installer? Makes deployment a bit easier.