Avisynth+

[pinterf]

I still have to work on the documentation. Unfortunately the bundled one generated from the rst files is hopelessly behind the actual changes which was done in Avisynth+. At least the content in avisynth.nl is more or less correct and up-to-date, but the latest changes I have made since december 2018, which appeared in 3.4.0, so there changes and additions are not refreshed there. E.g. the new Layer syntax and parameters.

[Atak_Snajpera]

Can somebody upload AviSynthPlus_3.4.0_Portable.7z somewhere outside those terrible github servers? I can't even download it. It just stops at random point.
https://i.postimg.cc/BQ68vwnS/Untitled-1.png

[LigH]

Interesting. I had similar issues with AdoptOpenJDK. But github releases are hosted in the Amazon cloud, they can push. If it doesn't go through, maybe your ISP throttles to blackmail Amazon to pay for better throughput? At least that's what they thought about Deutsche Telekom (https://github.com/AdoptOpenJDK/openjdk-build/issues/1349#issuecomment-552195893).

So, for statistics: What's your route?

And try to download at a different daytime. Late night in US / early morning in EU still got me 2 MB/s when they throttled. Then, another day, the throttling was not active, and I got 8 MB/s in the early EU evening which used to be the worst time with throttling.

[Atak_Snajpera]

Interesting. I had similar issues with AdoptOpenJDK. But github releases are hosted in the Amazon cloud, they can push. If it doesn't go through, maybe your ISP throttles to blackmail Amazon to pay for better throughput? At least that's what they thought about Deutsche Telekom (https://github.com/AdoptOpenJDK/openjdk-build/issues/1349#issuecomment-552195893).

So, for statistics: What's your route?

And try to download at a different daytime. Late night in US / early morning in EU still got me 2 MB/s when they throttled. Then, another day, the throttling was not active, and I got 8 MB/s in the early EU evening which used to be the worst time with throttling.

You might be right because downloading through my smartphone using LTE works super fast. If I switch to my wi-fi and use my cable ISP then everything just stops. I have no issues with other servers. Just that bloody github...

[real.finder]

happen to me also but you have to download them one by one to give all speed to only one since there are no Resume-able Downloads, and also you can try JDownloader which can Resume Downloads in most cases

[Atak_Snajpera]

Next attempt... aaaaaaaaaand it stopped!
https://i.postimg.cc/G2DJhFvQ/Untitled-1.png
I almost feel like in 99 when I had that 56k modem...

[StainlessS]

I've uploaded a plain 7z portable for 3.4.0 (well, technically, r2925 built from master, but the extra commit* only touched the READMEs, it's still otherwise-identical to 3.4). I also removed the GCC archive since videohelp still was (or, is at this time of writing) pointing at it as a 'portable' even when that was not the intention.

*the other's just the merge commit for that one change

VideoHelp is actually providing a zip file GCC version as portable version, here [DO NOT DOWNLOAD Portable version]:- https://www.videohelp.com/software/AviSynth-Plus

I reported the post with this message (limited in length), so hopefully it will be removed as an option from the VH post.
Link to AviSynth+ 3.4.0 Portable, NOT portable version, is GCC compiled version & cause major probs for most users.
The target zip has been removed/moved on github because videohelp pointing to it but you provide the actual zip so still a prob.

EDIT: Damn, I also just posted this post as a review in VH thread, unfortunately different bulletin board type code required, and it swallowed some of the quote,
ie the message I reported, and I cannot edit it. :(

[LigH]

@Atak_Snajpera: Your ISP is to be blamed here, or the one which controls a backbone yours depends on. Further down in your route, on a regional or national range. So complain to your ISP, and register issues in public issue portals. Also notify github about it, but remember, they don't take the blame.

[StainlessS]

VideoHelp is actually providing a zip file GCC version as portable version

I reported the post with this message (limited in length), so hopefully it will be removed as an option from the VH post.
Link to AviSynth+ 3.4.0 Portable, NOT portable version, is GCC compiled version & cause major probs for most users.
The target zip has been removed/moved on github because videohelp pointing to it but you provide the actual zip so still a prob.

Just checked, VideoHelp now hosting current AviSynth+ 3.4.0 Portable 7z file. [SHA-1 matches that on Github].

[jpsdr]

Tested with VDub2 (x86 & x64) 43943 and avs 3.40.
This works :

a0=colorbars(width=1920,height=1080,pixel_type="yv12").trim(0,9).ConvertBits(16).ConverttoYUV444()
a1=a0
StackVertical(a0,a1)
ConvertBits(8)

this doesn't :

a0=colorbars(width=1920,height=1080,pixel_type="yv12").trim(0,9).ConvertBits(16).ConverttoYUV444()
a1=a0
StackVertical(a0,a1)
#ConvertBits(8)

[StainlessS]

BITS=10
colorbars(pixel_type="YV12")
ConvertBits(BITS)
ConverttoYUV444 # When loaded in VD2, Bits 10,12,14,16 YUV444, Access Violation in Avisynth
StackVertical(Last,Last)
#ConvertBits(8) # OK


https://i.postimg.cc/FYT8NJQT/Untitled-01.jpg (https://postimg.cc/FYT8NJQT)

EDIT: Play OK in PotPlayer, but avisynth access violation when loaded into Vd2.
When 8 bit, or not converted to 444, then OK loaded in Vd2.

EDIT: Same

BITS=10
colorbars(pixel_type="YV24")
ConvertBits(BITS)
#ConvertBits(8) # OK

[pinterf]

Checking. Something wrong happens in my YUV444Y16 to Y416 conversion which is used when feeding vdub with this format.

EDIT: fixed in my repo, there are other things under work, PM if a build is needed for someone with this fix. (no immediate release yet).

[wonkey_monkey]

Here's my latest terrible/brilliant idea for AviSynth:

I write a lot of complicated scripts, and possibly the biggest hindrance is the fact that AviSynth doesn't automatically parse multi-line statements. I would absolutely love it if AviSynth had an alternative parsing mode (triggered by a first-line comment or something, like a shebang in a Bash script) where statements had to be ended with a semi-colon (;), like C, PHP, Javascript etc, to avoid needing backslashes to write multi-line statements. It'd make commenting out lines in the middle of statements simpler, too.

Anyway, on the basis that if you don't ask you won't get, that is my ask :) More of a suggestion, really, that it may percolate inside pinterf's brain until one fateful day when it leaks out into the code.

[StainlessS]

If the choices are "brilliant" or "terrible", I'll go with terrible.
Would be 100.0% for sure non backwards compatible, lots of exciting new bugs to contend with, and not really necessary.

Dont string gazillions of oop style whatsits together [just because you can, dont make it a good idea].
Suggest break your complicated lines into multiple lines, perhaps assigning temp value to temp variable, then can comment out entire lines.

EDIT: You might like to string lots of oop stuff together when all debugged and stuff, but whilst developing better to have separate lines of code.
In runtime code [eg scriptclip] separate lines may be a little slower [due to temp vars or implicit Last], but in non runtime, then should
have only small consequence [milliseconds] prior to first frame delivered [ie during graph building].

EDIT: By the way, VDub2 has multiline comment/uncomment, cant say I've ever used it. [CTRL/ALT/SHFT/C --- CTRL/ALT/SHFT/U]

[wonkey_monkey]

It'd be backwards compatible if it's only enabled by a specific string at the start of the script, e.g. #!multiline or something equally unlikely.

I was thinking more of individual calls with many parameters, which can't be broken up, but assigning to temp variables again and again for long strings of calls seems equally messy to me.

How much neater to be able to write like this and quickly comment out/rejoin single lines without having to worry about all the backslahes (which, I'd argue, only make it harder to read):


processed = source.
qtgmc.
flipvertical.
filter_with_many_parameters(
10,
20,
"mode", # you can even put a comment here if you want to
reverse = true
).
trim(50, 99).
selecteven;

[StainlessS]

source
qtgmc
flipvertical
filter_with_many_parameters(
\ 10,
\ 20,
\ "mode", [* you can even put a comment here if you want to *]
\ reverse = true
\ )
trim(50, 99)
selecteven
processed=Last # Or processed=selecteven




OK, but there are many issues of greater importance, leave this for when dev has a couple of weeks spare, nuttin' to do, and is a bit bored.

EDIT:
Further to above,
I get the impression that some apps parse the Avs script [at least to some degree], and if so then changes might break lots of apps,
not sure the devs of those apps would be over-the-moon bout it, eg AvsPMod, PotPlayer, VD2 ++.
[Maybe I is totally wrong]

[wonkey_monkey]

Bug report: it seems that the standard resizers (spline16, bicubic, and bilinear, at least) don't process the alpha planes of YUVA clips.

Reduceby2 does, though.

Edit: also, not a bug report as such, but addborders really should have the option not to convert the background to TV Range when adding borders to a YUV clip. Maybe it could be updated to adopt the color_yuv parameter of blankclip?

[pinterf]

I've added them as issues in order not to forget them
https://github.com/pinterf/AviSynthPlus/issues/43 and
https://github.com/pinterf/AviSynthPlus/issues/44

[wonkey_monkey]

Thanks pinterf.

[StainlessS]

This seems not to be true:- http://avisynth.nl/index.php/Layer
int level = (maximum)

The strength of the performed operation:

0 – no effect: base_clip is returned unchanged
257 (256 for YUY2) – maximum strength

AVS+ autoscaled – works without changes at all bit depths.

ie MAX at 8 bit RGB requires eg 257, $101, at 16 bit req 65537, $10001.


Question, how do you add the secret Opacity arg to Layer ? [AddFunction]
It dont seem to exist in the code.

extern const AVSFunction Layer_filters[] = {
{ "Mask", BUILTIN_FUNC_PREFIX, "cc", Mask::Create }, // clip, mask
{ "ColorKeyMask", BUILTIN_FUNC_PREFIX, "ci[]i[]i[]i", ColorKeyMask::Create }, // clip, color, tolerance[B, toleranceG, toleranceR]
{ "ResetMask", BUILTIN_FUNC_PREFIX, "c[mask]f", ResetMask::Create },
{ "Invert", BUILTIN_FUNC_PREFIX, "c[channels]s", Invert::Create },
{ "ShowAlpha", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)3 }, // AVS+ also for YUVA, PRGBA
{ "ShowRed", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)2 },
{ "ShowGreen", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)1 },
{ "ShowBlue", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)0 },
{ "ShowY", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)4 }, // AVS+
{ "ShowU", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)5 }, // AVS+
{ "ShowV", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)6 }, // AVS+
{ "MergeRGB", BUILTIN_FUNC_PREFIX, "ccc[pixel_type]s", MergeRGB::Create, (void*)0 },
{ "MergeARGB", BUILTIN_FUNC_PREFIX, "cccc", MergeRGB::Create, (void*)1 },
{ "Layer", BUILTIN_FUNC_PREFIX, "cc[op]s[level]i[x]i[y]i[threshold]i[use_chroma]b", Layer::Create },
/**
* Layer(clip, overlayclip, operation, amount, xpos, ypos, [threshold=0], [use_chroma=true])
**/
{ "Subtract", BUILTIN_FUNC_PREFIX, "cc", Subtract::Create },
{ NULL }
};


Any chance that there could be a means of accessing the multiple alternative plugin Parameter Lists ?
"$PluginFunctions$" or "$InternalFunctions$" extract same function name multiple times [for eg AssumeFPS] where multiple alternatvie parameter lists, but can
only extract a single parameter list for any one function name.
Need some way to 'get at' parameter lists using "$Plugin!" + "function name" + "!Param$".
Any chance ?

EDIT: Here v3.4.0 Layer param list with secret Opacity arg [and placement] :)
Layer "cc[op]s[level]i[x]i[y]i[threshold]i[use_chroma]b[opacity]f[placement]s"

[pinterf]

This seems not to be true:- http://avisynth.nl/index.php/Layer

You are right, not true.


Question, how do you add the secret Opacity arg to Layer ? [AddFunction]
It dont seem to exist in the code.

It exists

{ "Layer", BUILTIN_FUNC_PREFIX, "cc[op]s[level]i[x]i[y]i[threshold]i[use_chroma]b[opacity]f[placement]s", Layer::Create },

You have to check the master branch.
Either at my repo or the central avs+ repo (which is now a bit behind my repo, since I have some open work on my side)

I have to edit Layer wiki pages.

[pinterf]

O.K. here are the changes of 3.4 since my last public 2772 release

20191127 (dev 3.4.?)
--------------------------
- Fix: crash when outputting VfW (e.g. VirtualDub) for YUV444P16, other fixes for r210 and R10k formats
- WavSource: really use "utf8" parameter, fix some debug asserts
- TimeStrech: pass internal errors as Avisynth exception text (e.g. proper "Excessive sample rate!" instead of "unhandled C++ error")

20191021 3.4.0
--------------

- Merges in the MT branch, the current state of pinterf/MT, and packaging fixes
- Development HEAD is the master repo again in https://github.com/AviSynth/AviSynthPlus
- Bumps version to 3.4

20190829 r2915
--------------
- Changed: Trim, FreezeFrame, DeleteFrame, DuplicateFrame, Reverse and Loop are using frame cache again (similar to classic Avs 2.6)
- Enhanced: Expr: faster exp, log, pow for AVX2 (sekrit-twc)
- ConditionalReader: allow empty value in text file when TYPE string
- Fix: Expr: fix non-mod-8 issues for forced RGB output and YUV inputs
- New: AviSource support v308 and v408 format (packed 8 bit 444 and 4444)
- Fix: AviSource v410 source garbage (YUV444P10)
- Fix: Expr: when using parameter "scale_inputs" and the source bit depth conversion occured, predefined constants
(ymin/max, cmin/max, range_min/max/half) would not follow the new bit depth
- Fix: ConvertToRGB from 32bit float YUV w/ full scale matrixes (pc.601, pc.709, average)
- Fix: FlipHorizontal RGB48/64 artifacts
- Enhanced: a bit quicker FlipHorizontal
- Fix: RGB64 Blur leftmost column artifact
- Enhanced: quicker RGB24/48 to Planar RGB for AVX2 capable processors
- Fix: Strip alpha channel when origin is YUVA and using ConvertToYV12/ConvertToYV16/ConvertToYV24 funtions
- Fix: garbage with ConvertToYUY2 from 8 bit YUVA colorspaces
- Enhanced: Colorbars to accept RGB24, RGB48, YV411 and 4:2:2 formats for pixel_type (now all colorspaces are supported)
- Fix: shifted chroma in ColorBars and ColorBarsHD for YUV444PS
- Fix: ConvertToY8, ConvertToYV12, ConvertToYV16, ConvertToYV24 are now allowed only for 8 bit inputs.
Formerly these functions were allowed for 10+ bit colorspaces but were not converted to real 8 bit Y8/YV12/16/24.
Use ConvertToY, ConvertToYUV420, ConvertToYUV422, ConvertToYUV444 instead which are bit depth independent
- New parameter in ColorYUV, RGBAdjust, Overlay, ConditionalReader: string "condvarsuffix"
Allows multiple filter instances to use differently named conditional parameters.
- Fix: ColorBars: pixel_type planar RGB will set alpha to 0 instead of 255, consistent with RGB32 Alpha channel
- Fix: text colors for YUV422PS - regression since r2728 (zero-centered chroma)
- New: VirtualDub2 to display 8 bit planar RGB (needs up-to-date VirtualDub2 as well)
VfW interface to negotiate 8 bit Planar RGB(A) with FourCCs: G3[0][8] and G4[0][8], similar to the 10-16 bit logic
- Fix: planar RGBA Alpha on VfW was uninitialized because it wasn't filled.
- Layer: big update
- Support for all 8-32 bit Y and planar YUV/YUVA and planar RGB/RGBA formats
- New parameter: float "opacity" (0.0 .. 1.0) optionally replaces the previous "level". Similar to "opacity" in "Overlay"
- threshold parameter (used for lighten/darken) is autoscaled. Keep it between 0 and 255, same as it was used for 8 bit videos.
- new parameter: string "placement" default "mpeg2". Possible values: "mpeg2" (default), "mpeg1".
Used in "mul", "darken" and "lighten", "add" and "subtract" modes with planar YUV 4:2:0 or 4:2:2 color spaces (not available for YUY2)
in order to properly apply luma/overlay mask on U and V chroma channels.
- Fix some out-of-frame memory access in YUY2 C code
- Fix: Add proper rounding for add/subtract/lighten/darken calculations. (YUY2, RGB32, 8 bit YUV and 8 bit Planar RGB)
- Fix: "lighten" and "darken" gave different results between yuy2 and rgb32 when Threshold<>0
Fixed "darken" for RGB32 when Threshold<>0
Fixed "lighten" and "darken" for YUY2 when Threshold<>0
- Avisynth C interface header (avisynth_c.h):
- cosmetics: functions regrouped to mix less AVSC_API and AVSC_INLINE, put together Avisynth+ specific stuff
- cosmetics: remove unused form of avs_get_rowsize and avs_get_height (kept earlier for reference)
- use #ifndef AVSC_NO_DECLSPEC for AVSC_INLINE functions which are calling API functions
- define alias AVS_FRAME_ALIGN as FRAME_ALIGN (keep the AVS_xxxx naming convention)
- dynamic loader (avs_load_library) uses fallback mechanism for non-existant Avisynth+ specific functions, functions are usable for classic avisynth
- filter "Version": update year, removed avs-plus.net link
- Updated: TimeStretch plugin with SoundTouch 2.1.3 (as of 07.Jan 2019)
- Source/Build system
- rst documentation update (qyot27) in distrib\docs\english\source\avisynthdoc\contributing\compiling_avsplus.rst
- GCC-MinGW build, GCC 8.3 support
- CMake: Visual Studio 2019 generator support
- Clang (LLVM) support

[StainlessS]

Thanks P, was driving me nuts trying to find it in the v3.4.0 posted source.

EDIT:
filter "Version": update year, removed avs-plus.net link
Gonna need update year again soooon.

[pinterf]

Specifically for Layer:
See on github "distrib" folder: readme.txt and readme_history.txt (latter is a bit more verbose)
- Layer: big update
Previously Layer was working only for RGB32 and YUY2. Overlay was used primarily for YUV. Now Layer accepts practically all formats (no RGB24).
Note that some modes can be similar to Overlay, but the two filters are still different.
Overlay accepts mask clip, Layer would use existing A plane.
Overlay "blend" is Layer "add", Overlay "add" is different.
Lighten and darken is a bit different in Overlay.
Layer has "placement" parameter for proper mask positioning over chroma.

- Support for all 8-32 bit Y and planar YUV/YUVA and planar RGB/RGBA formats
When overlay clip is YUVA and RGBA, then alpha channels of overlay clip are used (similarly to RGB32 and RGB64 formats)
Non-alpha plane YUV/planar RGB color spaces act as having a fully transparent alpha channel (like the former YUY2 only working mode)

Note: now if destination is YUVA/RGBA, the overlay clip also has to be Alpha-aware type.
Now A channel is not updated for YUVA targets, but RGBA targets do get the Alpha updated (like the old RGB32 mode did)
Todo: allow non-Alpha destination and Alpha-Overlay
- New parameter: float "opacity" (0.0 .. 1.0) optionally replaces the previous "level". Similar to "opacity" in "Overlay"
For usage of "level" see http://avisynth.nl/index.php/Layer
"opacity" parameter is bit depth independent, one does not have to fiddle with it like had to with level (which was maxed with level=257 when RGB32 but level=256 for YUY2/YUV)
- threshold parameter (used for lighten/darken) is autoscaled.
Keep it between 0 and 255, same as it was used for 8 bit videos.
- new parameter: string "placement" default "mpeg2".
Possible values: "mpeg2" (default), "mpeg1".
Used in "mul", "darken" and "lighten", "add" and "subtract" modes with planar YUV 4:2:0 or 4:2:2 color spaces (not available for YUY2)
in order to properly apply luma/overlay mask on U and V chroma channels.
- Fix some out-of-frame memory access in YUY2 C code
- Fix: Add proper rounding for add/subtract/lighten/darken calculations. (YUY2, RGB32, 8 bit YUV and 8 bit Planar RGB)
- Fix: "lighten" and "darken" gave different results between yuy2 and rgb32 when Threshold<>0
Fixed "darken" for RGB32 when Threshold<>0
Fixed "lighten" and "darken" for YUY2 when Threshold<>0
All the above was done by specification:
Add: "Where overlay is brigher by threshold" => e.g. Where overlay is brigther by 10 => Where overlay > src + 10
Calculation: alpha_mask = ovr > (src + thresh) ? level : 0;
Add: "Where overlay is darker by threshold" => e.g. Where overlay is darker by 10 => Where overlay < src - 10
Calculation: alpha_mask = ovr < (src - thresh) ? level : 0;
The only correct case of the above was "lighten" for RGB32, even in Classic Avisynth. Note: Threshold=0 was O.K.
- (Just an info: existing lighten/darken code for YUY2 is still not correct, messing up chroma a bit,
since it uses weights from even luma positions (0,2,4,...) for U, and odd luma positions (1,3,5,...) for V)

[Atak_Snajpera]

I have a question about multithreading. Why avisynth plus does not support tiled based Mt like old avisynth.
If i'm not mistaken there was a MT function which was dividing frame in tiles and each tile was processed simultanously.

[pinterf]

I'm not aware that classic avisynth did such things. It's like what avstp used for mvtools and like jpsdr's _MT resizer and other plugin variants work.

[Atak_Snajpera]

I'm not aware that classic avisynth did such things. It's like what avstp used for mvtools and like jpsdr's _MT resizer and other plugin variants work.

I mean this http://avisynth.nl/index.php/MT

[pinterf]

Meanwhile Layer wiki is updated. I hope I included everything I have done with this filter.
http://avisynth.nl/index.php/Layer#Layer

[real.finder]

I have a question about multithreading. Why avisynth plus does not support tiled based Mt like old avisynth.
If i'm not mistaken there was a MT function which was dividing frame in tiles and each tile was processed simultanously.

cuz avs+ mt base on SEt changes, which see dividing frame for mt is bad idea, avstp and jpsdr's _MT in other hand did same thing as pinterf said but better and work in any avs, there are other method for MT that used in sorathread and ThreadRequest (https://forum.doom9.org/showthread.php?t=169714) but IIRC it's not work with avs+ well

[StainlessS]

All looks good to me, thanks muchly P.

[pinterf]

Bug report: it seems that the standard resizers (spline16, bicubic, and bilinear, at least) don't process the alpha planes of YUVA clips.

Fixed in source, available on my repo, no release yet.

(@jpsdr, this fix probably affects your _MT resizer versions because they are using this source)

[dREV]

Hi, I briefly wanted to ask about SetFilterMTMode("",) + Prefetch(1) if this is still relevant or not reading the previous earlier threads about this but wasn't sure if this has changed or not and if it is still relevant if this is linked with the amount of RAM one has on their PC which I only got 8 gigs or and the amount of (weak and heavy) filters in the chain.

It crashes when I go Prefetch(2) and I'm also on a Ryzen 5 2nd generation 2600 CPU if that helps.

[StainlessS]

I cant answer this, but you might want to provide a little more info for those that can.

Your script, & is it x86 or x64 Avs+.

[LigH]

Especially if you try to multi-thread QTGMC, be aware that it first will use as many EDI threads as cores, so using a higher prefetch value will multiply their threads even further; you may want to restrict that parameter in QTGMC when you have a CPU with many logical cores.

[jpsdr]

(@jpsdr, this fix probably affects your _MT resizer versions because they are using this source)

Thanks for the warning, i've checked, but in fact my getframe is very different, and i allready processed the alpha planes.

[StainlessS]

also, not a bug report as such, but addborders really should have the option not to convert the background to TV Range when adding borders to a YUV clip. Maybe it could be updated to adopt the color_yuv parameter of blankclip?

I've added them as issues in order not to forget them


Same for Letterbox too please P. [long time I've been a bit miffed with both Addborders and Letterbox for TV range only borders]

[wonkey_monkey]

Suppose I have two scripts, one of which imports the other. The first script gets a source:

source = AviSource("myfile.avi")

The second file returns a clip based on this source, but I'd also like the second file to be openable stand by itself. Is there a way to call AviSource and assign the the result to source at the top of the second file, but only if source has not already been defined? I tried VarExist like this:

source = VarExist(source) ? source : avisource("myfile.avi")

But I just get errors.

[StainlessS]

Maybe try [quotes around source in VarExist]

source = VarExist("source") ? source : avisource("myfile.avi")

[wonkey_monkey]

Ah, of course, that makes sense. Thanks.

[dREV]

I cant answer this, but you might want to provide a little more info for those that can.

Your script, & is it x86 or x64 Avs+.

Alright, for those that can answer

It's AviSynth+ 0.1.0 r2772 using the 32 bit version with the 10 bit hack pipeline for HEVC in MeGUI 2525.

Script plugins and import address
#rgtools
SetFilterMTMode("removegrain", MT_NICE_FILTER)
SetFilterMTMode("repair", MT_NICE_FILTER)
SetFilterMTMode("verticalcleaner", MT_NICE_FILTER)
SetFilterMTMode("clense", MT_NICE_FILTER)

#medianblur
SetFilterMTMode("medianblur", MT_MULTI_INSTANCE)
SetFilterMTMode("medianblurtemporal", MT_MULTI_INSTANCE)
SetFilterMTMode("average", MT_NICE_FILTER)
SetFilterMTMode("TMaskCleaner", MT_MULTI_INSTANCE)
SetFilterMTMode("checkmate", MT_NICE_FILTER)
SetFilterMTMode("Deblock", MT_NICE_FILTER)
SetFilterMTMode("msharpen", MT_MULTI_INSTANCE)
SetFilterMTMode("TColorMask", MT_NICE_FILTER)
SetFilterMTMode("Vinverse", MT_MULTI_INSTANCE)
SetFilterMTMode("Vinverse2", MT_MULTI_INSTANCE)

#masktools
SetFilterMTMode("mt_invert", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_binarize", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_inflate", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_deflate", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_inpand", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_expand", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_lut", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_lutxy", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_lutxyz", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_luts", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_lutf", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_lutsx", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_lutspa", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_merge", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_logic", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_convolution", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_mappedblur", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_makediff", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_average", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_adddiff", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_clamp", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_motion", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_edge", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_hysteresis", MT_MULTI_INSTANCE)
SetFilterMTMode("AddGrainC", MT_MULTI_INSTANCE)

# Source plugins
SetFilterMTMode("DGDecode_mpeg2source",MT_NICE_FILTER) #seems to work fine as 1
SetFilterMTMode("TFM", MT_MULTI_INSTANCE) #2 is faster. 1 crashes randomly.
SetFilterMTMode("TDecimate", MT_SERIALIZED) #1 gave error, 2 was slower than 3
SetFilterMTMode("TDeint", MT_MULTI_INSTANCE) # Mode 1 creates artifacts
SetFilterMTMode("SmoothLevels", MT_MULTI_INSTANCE) # Mode 1 freezes

# Filters from Dither 1.25.0. Tested by Firesledge (not extensively though)
SetFilterMTMode ("DitherPost", MT_NICE_FILTER)
SetFilterMTMode ("SmoothGrad", MT_NICE_FILTER)
SetFilterMTMode ("Dither_box_filter16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_bilateral16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_limit_dif16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_resize16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_out", MT_NICE_FILTER)
SetFilterMTMode ("Dither_removegrain16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_repair16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_median16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_add16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_sub16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_max_dif16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_merge16", MT_NICE_FILTER)
SetFilterMTMode("NNEDI3", MT_MULTI_INSTANCE)

SetFilterMTMode("FTurnLeft", MT_NICE_FILTER)
SetFilterMTMode("FTurnRight", MT_NICE_FILTER)

SetFilterMTMode("yadifmod", MT_NICE_FILTER)
SetFilterMTMode("ContinuityFixer", MT_NICE_FILTER)

ConvertBits(bits=8)

#filter varies here, crop, continuityfix

dither_convert_8_to_16()
#deband filter with mask=0 banding, only when no choice
f3kdbmod16()
s16 = last
DitherPost()

ConvertBits(bits=8)
FTurnRight()
##line darkening (Hysteria) filter sometimes here - 8 bit?
#Anti-Aliasing filter, maa2 usually - 8 bit?
FTurnLeft()

dither_convert_8_to_16()
s16.Dither_limit_dif16 (last, thr=0.25, elast=4.0)
SmoothGrad()
ly = GradFun3mod(thr=0.35,yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

DitherPost(mode=6)

ConvertBits(bits=16)
ConvertToStacked()
#grain filter
ConvertFromStacked().ConvertToDoubleWidth()

Prefetch(1)

Not sure if needed but some HEVC settings are sea, qcomp ranges from 60 to 80, veryslow speed, rc lookahead 40 and tune animation (majority of times then film) rest are almost max or max settings and a couple turned off like no sao, no amp, --no-strong-intra-smoothing, limit-refs=0, --no-limit-modes, and has both --fades and -dither

I've also tried it using the 64 bit version with filters and did not see much difference tho I only did a few tests.

Not sure why but when I use real.finder's maa2 anti-aliasing script https://forum.doom9.org/showthread.php?t=174121 when indexing the source it doesn't like each other and tend to get Access Violation. I have to use the script as Prefetch(0) to go thru then I have to edit the script back to Prefetch(1) to encode in MeGUI. Using older versions doesn't do this. If somebody can inform me on why this maybe occurring.

Especially if you try to multi-thread QTGMC, be aware that it first will use as many EDI threads as cores, so using a higher prefetch value will multiply their threads even further; you may want to restrict that parameter in QTGMC when you have a CPU with many logical cores.

OK, I haven't tried using that yet but I will keep your words down and note it on the read me file for that filter. Thanks for the info. :thanks:

[pinterf]

Same for Letterbox too please P. [long time I've been a bit miffed with both Addborders and Letterbox for TV range only borders]
New parameter color_yuv is done for AddBorders and LetterBox. Works exactly like in BlankClip.

[StainlessS]

New parameter color_yuv is done
Splendid :)

[StainlessS]

Wonkey,


processed = source.
qtgmc.
flipvertical.
filter_with_many_parameters(
10,
20,
"mode", # you can even put a comment here if you want to
reverse = true
).
trim(50, 99).
selecteven;


Just a bit of nit-pickin',
above script would not work in Avs [you is mixin' avs script and C].

[wonkey_monkey]

Wonkey,


Just a bit of nit-pickin',
above script would not work in Avs [you is mixin' avs script and C].

That was the point of my post - suggesting an alternate format that's more amenable to multi-lining.

[StainlessS]

I was suggesting that the trailing semi-colon would prevent it from working at full capacity, or at all :)
[even with auto appended lines]
EDIT: perhaps the semi-colon was deliberate ?, to show where appended lines thing is force ended, is that it ?

[wonkey_monkey]

Exactly, like C/C++.

[StainlessS]

So, guess that if implemented as suggested, then to avoid massive parsing, we will have to have statement terminators like everywhere, all of the time,
is that the suggestion ? (henceforth all avs script needs statement terminators, tis a change that might prevent adoption, do you have any other ideas ?).

[FranceBB]

Alright, for those that can answer

It's AviSynth+ 0.1.0 r2772 using the 32 bit version with the 10 bit hack pipeline for HEVC in MeGUI 2525.

Not related to the Access Violation, but to the quality instead.
You are bringing everything to 16bit stacked, filtering with f3kdb with 16bit precision, then you are using DitherPost as default to bring everything to 8bit to filter with maa2, lastly you're using DitherPost(mode=6) which is dithering with the Floyd Steinberg error diffusion, then you're converting it again from 8bit dithered to 16bit planar, then you're bringing it to stacked MSB and LSB again, you apply your denoise and then you convert from 16bit stacked to 16bit interleaved and you output it as interleaved.

Why?


Doesn't this make more sense?


#Here we're telling f3kdb to take your 8bit source, filter it with 16bit precision and output 16bit stacked

#Debanding 16bit stacked

f3kdb(input_depth=8, output_mode=1, output_depth=16)

#Now we're gonna truncate everything to 8bit,
#apply anti-aliasing with maa2 and then use the original 16bit stacked we received from f3kdb
#and apply only the changes made by maa2 thus retaining 16bit precision

#antialiasing 8bit, 16bit stacked output
s16 = last
DitherPost (mode=-1)
maa2()
Dither_convert_8_to_16 ()
s16.Dither_limit_dif16 (last, thr=1.0, elast=2.0)

#16bit stacked resize and debanding

ly = GradFun3mod(thr=0.35,yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)


#your 16bit stacked degrain filter

Something()

#16bit planar output (your target is x265 which will handle 16bit planar just fine; just remember to add --dither to the command line)

ConvertFromStacked()

[wonkey_monkey]

So, guess that if implemented as suggested, then to avoid massive parsing, we will have to have statement terminators like everywhere, all of the time,
is that the suggestion ? (henceforth all avs script needs statement terminators

Only those that start with the magic code to switch to the alternative parsing.

[LigH]

In Pascal it's exactly the opposite syntax: Semicola closing each line, a dot finishing "the sentence" (the program).