Avisynth+

[jpsdr]

Is it possible for a filter to set its MT mode on the constructor instead of inside AvisynthPluginInit3 ?
It's, for example, if a filter is MT_NICE_FILTER if parameter x=0, and MT_MULTI_INSTANCE if parameter x=1.

[pinterf]

New maintenance release for 32 bit/64 bit Avisynth+, also with XP versions.

Avisynth+ MT r1858 (https://github.com/pinterf/AviSynthPlus/releases/tag/r1858-MT-pfmod)

Changes from r1849:

r1858 MT-pfmod (20160531)

- fix: RGB resizers shift horizontally to the opposite direction when src_left param is used (reported by MysteryX)
- prevent fragmentation vfb buffer list for small sized vfbs
- fix: x64 compatible type in acmDriverEnum call in VD_Audio

The r1849 build was downloaded by 522 times from github in the last six weeks.
I hope the previous authors' enormous amount of time has not been wasted.

[Chikuzen]

Is it intentional that ColorbarsHD is 1288x720 and not 1280x720?
The avisynth doc also mentions 1288.

no.
ARIB STD-B28 says it should be 16:9 (and 75% colorbars should be 4:3).
The difference with the standard has occured because that's calculating the location of each colors with integer arithmatic.
I don't know why original author(IanB?) didn't calculate with floating point.

[Groucho2004]

@pinterf
Thanks for the new build.

@all
I made a "lean" installer for this new build, no docs/Filter SDK. It does however include the latest 2015 redistributables.
(AviSynth+ r1858.7z) (https://www.dropbox.com/sh/6kb3723po5oqd4b/AADbP8gIJ3YrHVoLU3joqJDma?dl=0)

[Reel.Deel]

@pinterf
Thanks!

What about creating a installer with latest versions from pinterf? ;)

Just yesterday I added installers for r1841 and r1847 to the wiki (http://avisynth.nl/index.php/AviSynth%2B#Downloads) (courtesy of stax76). Whenever he updates it I'll update the wiki also.


I made a "lean" installer for this new build, no docs/Filter SDK. It does however include the latest 2015 redistributables.
(AviSynth+ r1858.7z) (https://www.dropbox.com/sh/6kb3723po5oqd4b/AADbP8gIJ3YrHVoLU3joqJDma?dl=0)

Thanks, I'll add a link to on the wiki.

[qyot27]

Sidenote: similar to what happened a couple years ago with VS 2013 builds, Wine 1.9.x (i.e. the current dev branch) cannot use binaries built with VS 2015 yet. Even if you do have all the correct redist dlls available.

[burfadel]

@pinterf
Thanks for the new build.

@all
I made a "lean" installer for this new build, no docs/Filter SDK. It does however include the latest 2015 redistributables.
(AviSynth+ r1858.7z) (https://www.dropbox.com/sh/6kb3723po5oqd4b/AADbP8gIJ3YrHVoLU3joqJDma?dl=0)

The installer is 21.6 MB versus one for 1847 which is 4.02 MB. Also, once installed it didn't even seem to work. I use Staxrip, and Staxrip came up with an app error saying Avisynth wasn't installed. When I reinstalled 1847 and used the pinterf replacement archive files for 1858 it works fine!

[real.finder]

New maintenance release for 32 bit/64 bit Avisynth+, also with XP versions.

Avisynth+ MT r1858 (https://github.com/pinterf/AviSynthPlus/releases/tag/r1858-MT-pfmod)

Changes from r1849:

r1858 MT-pfmod (20160531)

- fix: RGB resizers shift horizontally to the opposite direction when src_left param is used (reported by MysteryX)
- prevent fragmentation vfb buffer list for small sized vfbs
- fix: x64 compatible type in acmDriverEnum call in VD_Audio

The r1849 build was downloaded by 522 times from github in the last six weeks.
I hope the previous authors' enormous amount of time has not been wasted.

thanks, and do you include 2.6.1 alpha 1 changes?

[Groucho2004]

I use Staxrip, and Staxrip came up with an app error saying Avisynth wasn't installed.
I don't know how staxrip determines if Avisynth is installed. It worked fine for me (32 and 64 bit).

[Groucho2004]

The installer is 21.6 MB versus one for 1847 which is 4.02 MB.
The staxrip AVS+ installer is heavily modified, does not have the MS redistributables and is 64 bit only.
I used the original AVS+ installer script and just removed the FilterSDK and Docs.

[pinterf]

thanks, and do you include 2.6.1 alpha 1 changes?
Not yet.

[stax76]

@burfadel

Groucho's installer is fine, StaxRip only reports wrong version, when you press F12 you can enter what version it actually is.

https://i.imgur.com/faqUH92.png

[Reel.Deel]

The staxrip AVS+ installer is heavily modified, does not have the MS redistributables and is 64 bit only.
I used the original AVS+ installer script and just removed the FilterSDK and Docs.

Thanks for the information. I'll remove stax76's installers from the wiki. I didn't know it was 64-bit only.

Wishful thinking: it would be nice to have an 'official' installer along side the binaries on GitHub.

[Groucho2004]

Wishful thinking: it would be nice to have an 'official' installer along side the binaries on GitHub.Building the installer is very easy and takes one minute. If pinterf is willing to supply an installer - I have uploaded my installer build environment here (https://www.dropbox.com/s/2lpsfuv3ggdo0lu/BuildAVSPLUS.7z?dl=0).


Install InnoSetup (http://www.jrsoftware.org/isdl.php) (innosetup-5.5.9-unicode.exe)
Update the binaries in "Bin_x86" and "Bin_x64"
Open "avs_plus.iss" with InnoSetup
Set "Version" (first line) to the correct revision
Build (Ctrl-F9)
Done.

[MysteryX]

Building the installer is very easy and takes one minute. If pinterf is willing to supply an installer - I have uploaded my installer build environment here (https://www.dropbox.com/s/2lpsfuv3ggdo0lu/BuildAVSPLUS.7z?dl=0).
This Inno Setup project should definitely be in GitHub.

[burfadel]

@burfadel

Groucho's installer is fine, StaxRip only reports wrong version, when you press F12 you can enter what version it actually is.

https://i.imgur.com/faqUH92.png

Ah ok, for some reason for me it came up as not installed when using his installer, even though it was and the files were in place.

The benefit of having the redists combined in the installer is two sided. Of course it makes it easier for people who don't already have VS2015 runtimes installed, but it does take up most of the space of the installer since the redists are in their original state. Also, the redists included are 14.0.23026, the latest 2015 runtimes available are 14.0.24018.

There are many fallacies of how the redists are handled in general, although it's not quite as bad as it used to be.

[MysteryX]

For setup, I think it's best to only download VS2015 if it's needed. It can easily be configured to download and install.

Modular InnoSetup Dependency Installer (http://www.codeproject.com/Articles/20868/NET-Framework-Installer-for-InnoSetup)

[burfadel]

For setup, I think it's best to only download VS2015 if it's needed. It can easily be configured to download and install.

Modular InnoSetup Dependency Installer (http://www.codeproject.com/Articles/20868/NET-Framework-Installer-for-InnoSetup)

That is a much better concept.

[Groucho2004]

The benefit of having the redists combined in the installer is two sided. Of course it makes it easier for people who don't already have VS2015 runtimes installed, but it does take up most of the space of the installer since the redists are in their original state. Also, the redists included are 14.0.23026, the latest 2015 runtimes available are 14.0.24018.
I agree. Additionally, the plugins included need the VS2012 runtimes. I'll make another build without them.
Anyway, the best thing an Avisynth user (or any user for that matter) can do is to use either ricktendo's or your AIO installer but knowledge about these and their benefits is not widespread unfortunately.

[pinterf]

I agree. Additionally, the plugins included need the VS2012 runtimes. I'll make another build without them.
I have just compiled the plugins for the very same reason, because unfortunately they are mixed. At the moment there are troubles with DirectShowSource, have to look into it. The header file in 2.6.1 alpha 1 was refreshed with build hints.

[Groucho2004]

At the moment there are troubles with DirectShowSource, have to look into it.
Do you have the DS SDK installed?

[MysteryX]

I agree. Additionally, the plugins included need the VS2012 runtimes. I'll make another build without them.
Anyway, the best thing an Avisynth user (or any user for that matter) can do is use either ricktendo's or your AIO installer but knowledge about these and their benefits is not widespread unfortunately.
With the link I posted above, you can easily make the setup install VS2012, VS2015 and whatever other dependency is needed, without bundling it into the setup file.

[Groucho2004]

With the link I posted above, you can easily make the setup install VS2012, VS2015 and whatever other dependency is needed, without bundling it into the setup file.
Maybe if there is ever a release of AVS+. For now, a note on the final installer dialog should suffice. This is still in Alpha stage.

[stax76]

The VapourSynth installer handles the VC++ runtime issue smarter, it's not included but downloaded if necessary.

https://github.com/vapoursynth/vapoursynth/tree/master/installer

[pinterf]

Do you have the DS SDK installed?
Not the right version. Only DirectX (February 2010). Downloading August, 2009.

[Groucho2004]

I made a "lean" installer for this new build, no docs/Filter SDK. It does however include the latest 2015 redistributables.
(AviSynth+ r1858.7z) (https://www.dropbox.com/sh/6kb3723po5oqd4b/AADbP8gIJ3YrHVoLU3joqJDma?dl=0)
I made a new r1858 build without the 2015 runtimes.

[Groucho2004]

Building the installer is very easy and takes one minute. If pinterf is willing to supply an installer - I have uploaded my installer build environment here (https://www.dropbox.com/s/2lpsfuv3ggdo0lu/BuildAVSPLUS.7z?dl=0).


Install InnoSetup (http://www.jrsoftware.org/isdl.php) (innosetup-5.5.9-unicode.exe)
Update the binaries in "Bin_x86" and "Bin_x64"
Open "avs_plus.iss" with InnoSetup
Set "Version" (first line) to the correct revision
Build (Ctrl-F9)
Done.
Added build environment without VC runtimes -> DL (https://www.dropbox.com/s/2i7ti3rbdz6zrb9/BuildAVSPLUS_no_redist.7z?dl=0).

[MysteryX]

Maybe if there is ever a release of AVS+. For now, a note on the final installer dialog should suffice. This is still in Alpha stage.
Yet it is very easy to add. There's no reason to not implement it now. For many, AVS+ in its current form is the best AVS so far. Especially for SVP users. They might appreciate to be able to bundle an installer that takes care of dependencies properly into the SVP update system.

However there were a few things that I needed to tweak to implement it myself, such as removing the German language option. One option is to just copy the code from my installer here (https://github.com/mysteryx93/NaturalGroundingPlayer/tree/master/Setup)

Edit: I see that in my folder, I only have the code for VC2010. The official project does have support for VC2010, 2012, 2013 and 2015. (http://www.codeproject.com/Articles/20868/NET-Framework-Installer-for-InnoSetup)

[ryrynz]

For many, AVS+ in its current form is the best AVS so far.

Without a doubt. Thank's to pinterf's efforts we have things in pretty good shape now.

[pinterf]

Successfully built DirectShowSource with VS2015.
Unlike avisynth.dll, with Platform Toolset set to v140 it runs on XP.
No need for v140_xp toolset, nor the extra /Zc:threadSafeInit- parameter. Why?

[Groucho2004]

No need for v140_xp toolset, nor the extra /Zc:threadSafeInit- parameter. Why?
My wild guess would be that only certain Win32 APIs/functions require these switches in order for the code to run on XP. For others, the object code created by the compiler would be the same with or without the switches.

[Reel.Deel]

Building the installer is very easy and takes one minute. If pinterf is willing to supply an installer - I have uploaded my installer build environment here (https://www.dropbox.com/s/2lpsfuv3ggdo0lu/BuildAVSPLUS.7z?dl=0).


Install InnoSetup (http://www.jrsoftware.org/isdl.php) (innosetup-5.5.9-unicode.exe)
Update the binaries in "Bin_x86" and "Bin_x64"
Open "avs_plus.iss" with InnoSetup
Set "Version" (first line) to the correct revision
Build (Ctrl-F9)
Done.

Wow, that was super easy! :cool:

---

@qyot27
I know a while back you were working on the documentation. I'm not sure if it was finished or not but from what I've seen it looks really good. How would I go about helping out?

https://web.archive.org/web/20160601135459/http://s33.postimg.org/d7b8r6n6z/avsplus_doc.jpg (https://web.archive.org/web/20160601135441/http://s33.postimg.org/u7u4zv08d/avsplus_doc.png)

[qyot27]

@qyot27
I know a while back you were working on the documentation. I'm not sure if it was finished or not but from what I've seen it looks really good. How would I go about helping out?

https://web.archive.org/web/20160601135459/http://s33.postimg.org/d7b8r6n6z/avsplus_doc.jpg (https://web.archive.org/web/20160601135441/http://s33.postimg.org/u7u4zv08d/avsplus_doc.png)
Yes, the RST/Sphinx conversion was finished, at least to the point that the documentation was on par with the docs from classic AviSynth at the time (2.6 RC1, and RC2-Final if the rc2integrate branch is considered (https://github.com/AviSynth/AviSynthPlus/pull/59/commits)).

The rc2integrate branch also adds a note into README.md about how to build the Sphinx documentation.

Actually editing the docs mostly only requires basic text editing, since the RST syntax is meant to be human-readable. Updating the docs against classic AviSynth's changes is pretty trivial, just do an dump of the page with lynx before and after the commit that changes a particular file(s) (so you don't have to deal with all the HTML), compare the changes in something like Meld, and adjust the corresponding *.rst files in AviSynth+'s docs to match the text content, adjusting for RST or Sphinx-specific syntax.

EDIT: After looking at the commits since 2.6 Final, there were no docs changes, so the docs in rc2integrate are still as up-to-date as classic's docs. Also, generally, some of those 2.6.1 changes in classic's CVS make me want to scream in agony.

[bilditup1]

The latest mt_modes list (http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest) says:

#note1: Can't use mode 1 or 2 on any filters if encoding 1080i files(480i works perfectly fine).

The alternative mt_modes list (https://gist.github.com/tp7/8899021) by tp7 further says:

#As far as I know, the only workaround seems to be running a deinterlacer right after the video source and running it as "MT_SERIALIZED",
#than running any desired filters after. Filters after the deinterlacer, seem to be able use any mode.

So:

Is this information still accurate? I am trying to use the 32-bit version of pinterf's latest mod with the following plugins:

DGDecodeIM (beta 50) (http://rationalqm.us/mine.html)
NNEDI3 (jpsdr 30/05/16) (http://forum.doom9.org/showthread.php?p=1662264#post1662264)
RgTools (tp7) (http://forum.doom9.org/showthread.php?p=1655989#post1655989)
MaskTool2 (tp7) (http://forum.doom9.org/showthread.php?p=1655989#post1655989)
MvTools2-pfmod (29/04/16) (http://forum.doom9.org/showthread.php?p=1762741#post1762741)

with A.SONY/real.finder's QTGMC mod (http://forum.doom9.org/showpost.php?p=1732845&postcount=2041).
What behavior should we expect with a 1080i source, if modes 1 or 2 are used normally? A crash? Artifacts? Very slow processing?
Since QTGMC uses several filters, which of them should be set to MT_SERIALIZED in order to avoid problems? NNEDI3 is one, I suppose, but others are used as well, right?
Specifically I'm curious about the filters used with the Medium and Fast presets of QTGMC.


Separately:
Is this note about ColorMatrix still accurate?
#note2: tried multiple files, seems to corrupt video even when it is the only filter in a script.
#tried mode 1, 2, and 3, none worked. however it works fine if MT isn't enabled.
#should ColorMatrix still be in the list? as a notice? or should it be removed?
If so, is there any alternative for doing colorspace conversions that works with AVS+ MT?


Without making any modifications to the MT modes file, on a 4770K@4.5Ghz, I seem to be getting 5-6.5 fps with MT enabled on a 1080i source being downscaled to 360p. By contrast, mainline AVS 2.6.1 with avs_tp (and ColorMatrix enabled) yields 6-7.5 fps, and AVS MT yields 12 fps but always crashes about 50-66% of the way through (again with ColorMatrix enabled). Is this within expected norms?

Also, this line in the MT modes files is incorrect:
SetFilterMTMode("DGDecIM", MT_SERIALIZED) #DGDecIM beta 50 2015/10/10
The correct line with the proper function name is:
SetFilterMTMode("DGSourceIM", MT_SERIALIZED) #DGDecIM beta 50 2015/10/10

[Reel.Deel]

@bilditup1

tp7's list is just an older revision of the latest MTModes list. He put it up on GitHub a while back as a backup because the original list was tampered with. Unfortunately it hasn't been updated since in over a year.

Regarding the notes, I'm not sure who wrote that or how or when it was tested. It was probably before this issue was fixed: https://github.com/AviSynth/AviSynthPlus/issues/37
It's probably best to test and report back if you find any problems.

All filters used by QTGMC work with MT mode 1 or 2 and they're already included in the MT Modes list (except for some filters from MVTools). I've successfully used QTGMC with:


SetFilterMTMode("WhateverSource" 3)
SetFilterMTMode("DEFAULT_MT_MODE", 2)

WhateverSource("somevideo.file")
QTGMC()

Prefetch(x)

or


Import("MTModes.avsi")
SetFilterMTMode("WhateverSource" 3)
SetFilterMTMode("DEFAULT_MT_MODE", 2)

WhateverSource("somevideo.file")
QTGMC()

Prefetch(x)

I do not use ColorMatrix so I don't if it crashes with MT or not. I use dither tools to change colorimetry.

Thanks for the DGSourceIM report. I'll correct it right now.

[bilditup1]

@bilditup1

tp7's list is just an older revision of the latest MTModes list. He put it up on GitHub a while back as a backup because the original list was tampered with. Unfortunately it hasn't been updated since in over a year.

Regarding the notes, I'm not sure who wrote that or how or when it was tested. It was probably before this issue was fixed: https://github.com/AviSynth/AviSynthPlus/issues/37
It's probably best to test and report back if you find any problems.


Thanks for all that; will do. I am testing with QTGMC and without ColorMatrix now and will do another one with CM later.


All filters used by QTGMC work with MT mode 1 or 2 and they're already included in the MT Modes list (except for some filters from MVTools). I've successfully used QTGMC with:


OK. I am using QTGMC atm without issue. Let's see if it holds. Hopefully we'll be able to remove these disclaimers and prevent this kind of confusion :)


I do not use ColorMatrix so I don't if it crashes with MT or not. I use dither tools to change colorimetry.


Off-topic I know, but how does this work? I found this snippet at the wiki:


Dither_convert_8_to_16 ()
Dither_resize16 (1280, 720)
Dither_convert_yuv_to_rgb (matrix="601", output="rgb48y", lsb_in=true)
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="709", lsb=false, mode=0)


For HD to SD conversion, should I just get rid of the resize, and switch the matrix parameters in the third and seventh lines? I don't understand what I'm looking at, specifically the SelectEvery() lines.

Thanks for the DGSourceIM report. I'll correct it right now.

OK great! No problem.

[Reel.Deel]

OK. I am using QTGMC atm without issue. Let's see if it holds. Hopefully we'll be able to remove these disclaimers and prevent this kind of confusion :)

Indeed, hopefully more people will help out in testing and validating filters. This list was meant to be community-driven but so far only a few people have actually contributed. :(
Off-topic I know, but how does this work? I found this snippet at the wiki:


Dither_convert_8_to_16 ()
Dither_resize16 (1280, 720)
Dither_convert_yuv_to_rgb (matrix="601", output="rgb48y", lsb_in=true)
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="709", lsb=false, mode=0)


For HD to SD conversion, should I just get rid of the resize, and switch the matrix parameters in the third and seventh lines? I don't understand what I'm looking at, specifically the SelectEvery() lines.


That script is on the wiki upscales SD to HD content, you want to downscale so use this instead:


Dither_convert_8_to_16 ()
Dither_resize16 (640, 480, csp="YV24") # change to the desired dimensions
Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y", lsb_in=true) # convert to RGB using the 709 color matrix commonly used in HD content
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="601", lsb=false, mode=0, output="YV12") # convert to YUV using the 601 color matrix commonly used in SD content

First the YUV clip is scaled from HD to SD. Then it gets converted to RGB and finally back to YUV with the appropriate matrix for SD. The SelectEvery() is used to process 48-bit RGB clips, from the docs:
48-bit RGB. The components R, G and B are conveyed on three YV12 or Y8 (if supported) stack16 clips interleaved on a frame basis.
I added csp="YV24" to Dither_resize16 to avoid any unnecessary resizing on the chroma planes. Finally, the output will be 8-bit YV12 if you want 16-bit just set lsb=true, if you want another colorspace just change the output parameter.

[bilditup1]

Indeed, hopefully more people will help out in testing and validating filters. This list was meant to be community-driven but so far only a few people have actually contributed. :(


Yeah they must not have if that's stayed in there for two years. That's rough. Whelp, I'll be sure to report anything I find personally, at least :)


That script is on the wiki upscales SD to HD content, you want to downscale so use this instead [...]


Thanks for this, quite helpful. I know I'm really hijacking the thread here, but have a couple more questions.

Dither_resize16 (640, 480, csp="YV24") # change to the desired dimensions

So it is best to do the resize now, with Dither's resize, as opposed to just putting a Spline36Resize() at the end?

Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y", lsb_in=true) # convert to RGB using the 709 color matrix commonly used in HD content
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="601", lsb=false, mode=0, output="YV12") # convert to YUV using the 601 color matrix commonly used in SD content
OK so basically, you just switched the matrix parameters between the first and last lines here. Cool.
The SelectEvery() is used to process 48-bit RGB clips, from the docs:
48-bit RGB. The components R, G and B are conveyed on three YV12 or Y8 (if supported) stack16 clips interleaved on a frame basis.
But then I'm wondering why we're using 48-bit RGB - I don't really understand the advantages or necessity either way. Is this because of the Dither_convert_8_to_16 () before?

[Reel.Deel]

Yes, the RST/Sphinx conversion was finished, at least to the point that the documentation was on par with the docs from classic AviSynth at the time (2.6 RC1, and RC2-Final if the rc2integrate branch is considered (https://github.com/AviSynth/AviSynthPlus/pull/59/commits)).

The rc2integrate branch also adds a note into README.md about how to build the Sphinx documentation.

Actually editing the docs mostly only requires basic text editing, since the RST syntax is meant to be human-readable. Updating the docs against classic AviSynth's changes is pretty trivial, just do an dump of the page with lynx before and after the commit that changes a particular file(s) (so you don't have to deal with all the HTML), compare the changes in something like Meld, and adjust the corresponding *.rst files in AviSynth+'s docs to match the text content, adjusting for RST or Sphinx-specific syntax.

EDIT: After looking at the commits since 2.6 Final, there were no docs changes, so the docs in rc2integrate are still as up-to-date as classic's docs. Also, generally, some of those 2.6.1 changes in classic's CVS make me want to scream in agony.

Thanks for the information. Hopefully it won't be too hard.

I would like too add some updates from the wiki, mainly the internal filters which raffriff42 has worked on (sadly the official documentation does not include these changes, see here (http://forum.doom9.org/showthread.php?p=1754316#post1754316)). Also add a few things from the AviSynth+ wiki page, and maybe start documenting MT.

[bilditup1]

Using AVSMeter 2.2.8 with r1858, it appears to work most of the way through...and then just sort of hangs with zero CPU activity.

Click here (https://mega.nz/#!jIQUjTbT!mcKmFFu61QoRJi71GtdOPNxNVscc7bzFKSAJzwTo_pM) for a screenshot of where it stopped and the script I used. Source is still 1080i60 MPEG2, OS is Win10x64.

[MysteryX]

Is there any alternative for doing colorspace conversions that works with AVS+ MT?
The problem with ColorMatrix is that it can cause banding due to rounding errors as it processes with integers. Processing with 16-bit-depth avoids this problem.

In addition to DitherTools, you can try AviSynthShader. You can convert color matrix and resize your image through the GPU. Might be faster than DitherTools, not sure.

[Reel.Deel]

Using AVSMeter 2.2.8 with r1858, it appears to work most of the way through...and then just sort of hangs with zero CPU activity. Attached is a screenshot of where it stopped and the script I used. Source is still 1080i60 MPEG2, OS is Win10x64.

Can share attachments elsewhere? Sometimes it takes a while to get approved.

Regarding your other questions, if you post them in appropriate thread (http://forum.doom9.org/showthread.php?t=153589) I'll gladly help where I can.

[bilditup1]

The problem with ColorMatrix is that it can cause banding due to rounding errors as it processes with integers. Processing with 16-bit-depth avoids this problem.

In addition to DitherTools, you can try AviSynthShader. You can convert color matrix and resize your image through the GPU. Might be faster than DitherTools, not sure.

I didn't know that ColorMatrix was basically obsolete, will keep that mind. Thanks for the info.

I'm not sure who is in charge of the AviSynth wiki, but maybe this can be pointed out somewhere? Like maybe here (http://avisynth.nl/index.php/External_filters#Chroma_correction), where neither DitherTools nor AviSynthShader are mentioned at all?

ED: I just realized that anyone can sign up there, and just did. But I don't think I'm really qualified to begin mucking around there just yet.

[bilditup1]

Can share attachments elsewhere? Sometimes it takes a while to get approved.
Hmph, I hadn't noticed. I've uploaded them to mega.nz and placed the link in the original post above. Here it is again. (https://mega.nz/#!jIQUjTbT!mcKmFFu61QoRJi71GtdOPNxNVscc7bzFKSAJzwTo_pM)


Regarding your other questions, if you post them in appropriate thread (http://forum.doom9.org/showthread.php?t=153589) I'll gladly help where I can.

Aight. But I think this:
Processing with 16-bit-depth avoids this problem.
basically answers one of them already. I'll ask there too though, as I can't be the only one curious about this.

[bilditup1]

Here it is again. (https://mega.nz/#!jIQUjTbT!mcKmFFu61QoRJi71GtdOPNxNVscc7bzFKSAJzwTo_pM)

Balls, I never modified this line to what it should have properly been:
SetFilterMTMode("WhateverSource", 3)
The MT mode for my source filter was setup properly in the mt_modes file I imported at the beginning, so presumably this line just did nothing. Still...sloppy of me, eh

[qyot27]

Thanks for the information. Hopefully it won't be too hard.

I would like too add some updates from the wiki, mainly the internal filters which raffriff42 has worked on (sadly the official documentation does not include these changes, see here (http://forum.doom9.org/showthread.php?p=1754316#post1754316)). Also add a few things from the AviSynth+ wiki page, and maybe start documenting MT.
It made it a lot easier for me to proof the changes between old (HTML) and new (Sphinx) versions by using the Tile View extension in Firefox, so I could see both side-by-side instead of needing to switch between tabs, with Notepad2 (or Leafpad, since I was under Linux while doing this) off to the side to edit the actual RST files.

It's really as simple as 'make html' in the distrib/docs/english directory, so long as you've installed Python and Sphinx. Sphinx will tell you if there are syntax errors in the files, and if the built HTML version is open in your browser, you can see the errors and work them down until it complies. And it'll also only rebuild the files that have been touched, rather than needing to rebuild the entire doc tree.

[bilditup1]

Using AVSMeter 2.2.8 with r1858, it appears to work most of the way through...and then just sort of hangs with zero CPU activity.

Click here (https://mega.nz/#!jIQUjTbT!mcKmFFu61QoRJi71GtdOPNxNVscc7bzFKSAJzwTo_pM) for a screenshot of where it stopped and the script I used. Source is still 1080i60 MPEG2, OS is Win10x64.

I ran this again, but this time using MeGUI and encoding to x264. The first time, MeGUI appears to have totally crashed. The second time, it completed without issue, at 10.17fps. The latter is pretty good. I will continue doing tests and reporting back, especially with respect to how well 1080i works and regarding matrix operations.

[pinterf]

Using AVSMeter 2.2.8 with r1858, it appears to work most of the way through...and then just sort of hangs with zero CPU activity.

Click here (https://mega.nz/#!jIQUjTbT!mcKmFFu61QoRJi71GtdOPNxNVscc7bzFKSAJzwTo_pM) for a screenshot of where it stopped and the script I used. Source is still 1080i60 MPEG2, OS is Win10x64.

What happens when you trim the video right after the source filter and process only around the part when the freeze occurs. If the position of the freeze also moves back, the problem is source dependent. Maybe the problem is not with the source itself, but filters can behave content dependent e.g. at a scene change.

[bilditup1]

What happens when you trim the video right after the source filter and process only around the part when the freeze occurs.

In other words, everything after frame #34406, per the screenshot?

If the position of the freeze also moves back, the problem is source dependent.

Not sure what this means, sorry?

Maybe the problem is not with the source itself, but filters can behave content dependent e.g. at a scene change

OK, so that could be a problem with this artificial test of mine, where I'm taking 1,000 frames out of every 5,000, to avoid having to do a full encode that I don't even need? That should cause pretty abrupt scene changes, in theory.

[pinterf]

In other words, everything after frame #34406, per the screenshot?


Some month ago I fixed a problem when the memory consumption in avisynth suddenly increased after the 33000th frame, then at around 39000th, etc.. When I trimmed the source to begin at the 32000th frame, the same thing happened 32000 frames earlier, at the 1000th, 7000th, etc. frames. The problem was source dependent. And it turned out that there had been heavy camera shake at that problematic position. One of the filters detected a new scene (too much difference between neighbouring frames) and other parts of that filter were involved in processing and caused memory leak.

Such a basic script must not cause freeze should it be artificial or not.