Avisynth+

[pinterf]

Thanks to raffriff42, who provided me a nice skeleton page, Expr got an info page.
It's still ugly, I'll format it properly when I'm fiddling out how to do that. Now I only poured some infos there.
Enjoy (or not :) ) http://avisynth.nl/index.php?title=Expr

[wonkey_monkey]

With a YUVA clip, IsY() and IsYUV() seem to return false. Is that intended behaviour? I've been relying on https://forum.doom9.org/showthread.php?p=1783714 as a reference on colour spaces, but it's not clear on this point.

---

Also that page makes reference to ComponentCount but the latest avisynth.h only seems to have NumComponents...? Is the latter the eventual form of the former, I guess?

If anybody ever thinks of it, HasY(), HasU(), HasG(), HasA() etc would be awesome...

[raffriff42]

YUV444P8 is YUV but not YUVA or Y-only
YUVA444P8 is YUVA but not YUV or Y-only
Y8 is Y and YUV but not YUVA

I tried to create a hierarchy (tree view) on the Avisynthplus_color_formats (http://avisynth.nl/index.php/Avisynthplus_color_formats) page.
See also the Clip_properties (http://avisynth.nl/index.php/Clip_properties#Video:_Color_Format) page.

HasA() exists and it's called HasAlpha.
HasU() does not exist, but you can call try { ExtractU (http://avisynth.nl/index.php/Extract) } catch { ...}

[wonkey_monkey]

Thanks - seems a little messy but I think it's clearer. Do all Y-only formats return IsYUV()=true? Or just Y8?

[raffriff42]

All the tests hold true regardless of bit depth.

If you want more confusion, consider that the new RGB(A) formats are planar; you can't call ConvertBits(x) on an RGB32 clip, you must call ConvertToPlanarRGBA first. I have posted a utilities script, called Utils-r41.avsi (http://avisynth.nl/images/Utils-r41.avsi), that (among other things) hides this complexity behind To16bit and ToHibit(bits)

[qyot27]

I tried to create a hierarchy (tree view) on the Avisynthplus_color_formats (http://avisynth.nl/index.php/Avisynthplus_color_formats) page.
See also the Clip_properties (http://avisynth.nl/index.php/Clip_properties#Video:_Color_Format) page.
Two nitpicks:
There's a typo on YUVA444P claiming classic AviSynth has it.

The YUV422P10 entry is showing v210's data. IMO, v210 being interleaved and VfW-only should only be mentioned in the footnotes at the bottom, not in the table itself. The notes column could read like:
aka P210 (special-case: V210 output available via override§)
(or 'global OPT_Enable_V210()' instead of 'override'). But as it is right now, it's highly misleading since YUV422P10 is planar, is used internally in AviSynth+, and isn't VfW-only.


If you want more confusion, consider that the new RGB(A) formats are planar; you can't call ConvertBits(x) on an RGB32 clip, you must call ConvertToPlanarRGBA first. I have posted a utilities script, called Utils-r41.avsi, that (among other things) hides this complexity behind To16bit and ToHibit(bits)
Well, for ConvertBits(16) you'd get RGBA64 - and as far as I'm aware, that should preserve the alpha. The question is whether RGBA64 is actually useful, or whether most destination programs expect 16-bit planar RGBA if working with >8bit and alpha.

[raffriff42]

qyot27, thanks for fact-checking, I'll fix.

>for ConvertBits(16) you'd get RGBA64
IIRC I used to get an error trying that, but you're right, it works.

[wonkey_monkey]

HasA() exists and it's called HasAlpha.


I don't see it in the avisynth.h dated 20171207. I'll use NumComponents()==4, it seems like that should work.

[pinterf]

I don't see it in the avisynth.h dated 20171207. I'll use NumComponents()==4, it seems like that should work.
HasAlpha is an Avisynth+ script function and has no direct mapping to a VideoInfo helper function.
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/parser/script.cpp#L1400

[pinterf]

Don't know if vmovntdqa reg,reg is valid or not but it seems to be not. The crash occurs in merge_avx2:

00070 8d 40 20 lea eax, DWORD PTR [eax+32]

; 70 : __m256i src1 = _mm256_stream_load_si256(reinterpret_cast<__m256i*>(p1+x));

00073 c5 fe 6f 40 e0 vmovdqu ymm0, YMMWORD PTR [eax-32]
00078 c4 e2 7d 2a c8 vmovntdqa ymm1, ymm0 ****CRASH HERE! ILLEGAL INSTRUCTION VS15.5.1!!!****

; 71 : __m256i src2 = _mm256_stream_load_si256(const_cast<__m256i*>(reinterpret_cast<const __m256i*>(p2+x)));
0007d c5 fe 6f 44 02 e0 vmovdqu ymm0, YMMWORD PTR [edx+eax-32]
00083 c4 e2 7d 2a c0 vmovntdqa ymm0, ymm0


Will update to 15.5.2 and see what happens.

EDIT:
With VS 15.5.2 the code still fails. Replaced stream_load with normal load, it's O.K.
Two weeks ago I have reported it and made a minimal project for MS which still exhibited the problem. And they fixed. One less bug.
https://developercommunity.visualstudio.com/content/problem/174767/illegal-avx2-instruction-by-c-for-mm256-stream-loa.html

[kuchikirukia]

I'm seeing some very strong halos using QTGMC 3.357 with Avisynth+ r2580-MT that's not in avs+ 2.6.0.5 or regular avs 2.6.

[real.finder]

I'm seeing some very strong halos using QTGMC 3.357 with Avisynth+ r2580-MT that's not in avs+ 2.6.0.5 or regular avs 2.6.

avs+ 2.6.0.5 ?

[raffriff42]

On a hunch, try the latest MaskTools (https://github.com/pinterf/masktools/releases/). (I've seen artifacts with 3.357 that seem to be gone now)

[real.finder]

since there are many plugins dll's that didn't port to x64 including the closed source plugins, is there some ways to make the 32 bit one work in 64 processes? I note this http://www.dllwrapper.com/ but couldn't build wrapped dll successfully, and even if I did, it will work one day only (need to buy it)

Then I guess you must encode 4k or 1080 bluray videos then. Is there a way for the 32bit plugins work with the x64 avisynth+? Or a way to make them backward compatible?

let's back to this, I note that squid_80 did build some close source plugins for x64 back then https://forum.doom9.org/showthread.php?p=1104481#post1104481

since there are some doom9 members that has Intel's compiler like Groucho2004, I think they can did build some too at least for many plugins that needed

[Dion]

I'm seeing some very strong halos using QTGMC 3.357 with Avisynth+ r2580-MT that's not in avs+ 2.6.0.5 or regular avs 2.6.

Seeing this too.. Same plugins versions.

[LigH]

A screenshot and an AVSMeter report about available plugins may be helpful. Guessing without facts is so uncertain. Just imagine several plugins providing functions with the same name (like RemoveGrain + RGTools), and an older plugin being preferred over a newer one.

[Aktan]

Did StackHorizontal/StackVertical change in AVS+? Using this simple script, the shorter clip still continues for whatever reason:

left = AVISource("test1.avi", pixel_type="YUY2").trim(2000, 3000)
right = AVISource("test1.avi", pixel_type="YUY2").trim(3000, 3500)
StackHorizontal(left, right)

test1.avi is over 5000 frames long.

[LigH]

AviSynth Wiki: Filters with multiple input clips (http://avisynth.nl/index.php/Filters_with_multiple_input_clips)

StackHorizontal, StackVertical: Framecount – longest clip: the last frame(s) of the shorter clip(s) are repeated until the end

Is it different for AviSynth+ that the shorter clip keeps playing, instead of freezing its last frame?

[pinterf]

AviSynth Wiki: Filters with multiple input clips (http://avisynth.nl/index.php/Filters_with_multiple_input_clips)

StackHorizontal, StackVertical: Framecount – longest clip: the last frame(s) of the shorter clip(s) are repeated until the end

Is it different for AviSynth+ that the shorter clip keeps playing, instead of freezing its last frame?
left is 1000 frames, right is 500 frames long.
The resulting clip length is the maximum of the input clip lengths.
The question: what happens when in the above samples Trim(3000,3500) is requested with frame numbers over 500?

Trim (at least in Avs+) does not check the requested frame number, it passes over the task to its child filter:
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/edit.cpp#L258

The question that this is a planned behaviour or not?

[wonkey_monkey]

The question that this is a planned behaviour or not?

I like it, whether it's planned or not. It's something I was thinking of suggesting, but is probably too niche and too open-ended a task to properly implement - for clips to keep track of their true starts and ends, so that you can untrim. It would make things like dissolves easier (for me, anyway) - just trim the to the right lengths, and dissolve will extend them as much as needed to keep the result the same length as a plain splice no matter what length dissolve is used.

[Aktan]

AviSynth Wiki: Filters with multiple input clips (http://avisynth.nl/index.php/Filters_with_multiple_input_clips)

StackHorizontal, StackVertical: Framecount – longest clip: the last frame(s) of the shorter clip(s) are repeated until the end

Is it different for AviSynth+ that the shorter clip keeps playing, instead of freezing its last frame?

Yep, this is what is happening. What is weird is, my friend got it that it will keep playing on the first StackHorizontal but the 2nd one will freeze the frame. In fact all StackHorizontals after his first one does freeze the frame. I have not figured out a simple script to show this behavior yet, but I'm working on it.

[raffriff42]

If you don't want repeating frames, you need to trim the resulting clip:StackHorizontal(A, B, C)
Trim(0, Min(A.FrameCount, B.FrameCount, C.FrameCount))

[StainlessS]

If you don't want repeating frames, you need to trim the resulting clip:StackHorizontal(A, B, C)
Trim(0, Min(A.FrameCount, B.FrameCount, C.FrameCount))

Would this be better

StackHorizontal(A, B, C)
Trim(0, - Min(A.FrameCount, B.FrameCount, C.FrameCount))
# ^


ie minus, meaning number of frames, rather than end at minimum end frame + 1

[raffriff42]

Yup, that would be better.

[Aktan]

If you don't want repeating frames, you need to trim the resulting clip:StackHorizontal(A, B, C)
Trim(0, Min(A.FrameCount, B.FrameCount, C.FrameCount))

Thanks for your help, but what my friend and I want is actually to keep the longer length and freeze the shorter clip. You see, it helps in comparison videos. The workaround is to use FreezeFrame, but it be nice if we didn't need to use that.

[StainlessS]

Yep, that is a bug, B not truncated. (ornamental trim EndFrame/Framecount/Length, leastwise when in stack)


A=Colorbars.KillAudio.Trim(0,-10).ShowFrameNumber # 10 frames
B=A.Trim(0,-1) # 1 Frame

StackHorizontal(A,B) # Comment one of these out
#Stackvertical(A,B)


EDIT: This gives an even more interesting result (Start trimmed but end not).

B=A.Trim(5,-1) # 1 Frame


EDIT: Makes no difference if specifying End Frame (+ve end) or FrameCount (-ve end), or length (Length=n).


Trim (at least in Avs+) does not check the requested frame number, it passes over the task to its child filter:


In this case Trim() is the child/source filter that StackXXX expects to check for valid frames.
Current standard AVS method must remain the default, if changing as per DavidHorman, then would require additional
args to both StackXXX and trim, methinks (or passed by StackXXX to trim child).

EDIT: It always confused me as to why child clip is source to a filter, I'm assuming that child filter is also the source filter to current filter.
[It always seemed a bit more sensible to me if it were the other way around].

EDIT: OK, think I figured it out, child is the child of the previous filter, but to current filter it is the parent, or maybe not, who knows.

[Aktan]

Here is something interesting, if you add Info() to the trim on B, it works fine:

A=Colorbars.KillAudio.Trim(0,-10).ShowFrameNumber # 10 frames
B=A.Trim(0,-1).Info() # 1 Frame

StackHorizontal(A,B) # Comment one of these out
#Stackvertical(A,B)

Edit: Even replacing Info() with AddBorders(0,0,0,0) would fix it.

[StainlessS]

Obviously, there Info is checking valid range for end frame [vi.num_frames], and doing Trim's job for it.

Trim must currently set vi.num_frames in its result clip, but then ignore it.
It always has to be the filter nearer to source that judges what range is valid, with ultimate responibilty being with the
source fliter itself (eg AviSource or Colorbars), but in this case trim assumes (or should assume) that resonsibility for all following
filters, quite a lot of filters (all of mine, unless bugged), check for valid frame as provided in vi.num_frames by its source
filter. If no filters check (and some dont) for valid frame, then source (eg AviSource) must do it for them, trim must take on that
role if added to filter chain, indeed, it is its raison d'être.

If some other functionality added, then probably best if a totally new filtername is chosen, DavidHormam_Trim(), or something :)

[real.finder]

If some other functionality added, then probably best if a totally new filtername is chosen, DavidHormam_Trim(), or something :)

Agreed, or even better, added new parameter in the last of parameters list with Default vale that not break old behavior

[wonkey_monkey]

If some other functionality added, then probably best if a totally new filtername is chosen, DavidHormam_Trim(), or something :)

That sounds like a fantastic idea. I also propose that davidhorman_trim(100,200) would return frames 100-199 (100 frames) just to confuse people even further.

(I do think it makes more sense but I'm not such an optimist that I'd expect it to change now)

[raffriff42]

Lots of filters added to clip B eliminate the phantom frames:A=Colorbars.KillAudio.Trim(0,-10).ShowFrameNumber # 10 frames
#[[
#B=A.Trim(0, -1) ## broken
#B=A.Trim(0, -1).Info ## fixed
#B=A.Trim(0, -1).Invert.Invert ## fixed
#B=A.Trim(0, -1).TurnLeft.TurnRight ## fixed
#B=A.Trim(0, -1).AssumeFrameBased ## broken
#B=A.Trim(0, -1).AssumeFPS(A) ## broken
B=A.Trim(0, -1).ChangeFPS(A) ## fixed
#]]
StackHorizontal(A,B)

[StainlessS]

That sounds like a fantastic idea. I also propose that davidhorman_trim(100,200) would return frames 100-199 (100 frames)

Sounds great, could give it a monika of DavidHorman_VirtualDub_Compatible_Trim().

[LigH]

@raffriff42:

So, which of them is the most performant "NOP filter" preserving the specified behaviour? ... :o J/K

[StainlessS]

I would think that the raw elegance of current AVS+ trim is the most performant NOP, really need more tests from those willing to partisipate.

EDIT: Above, guess I misinterpreted Ligh's post, 8 or 9 pints of bitter seem to have that effect on me.

[wonkey_monkey]

It must be ChangeFPS, since it has no need to do anything to the actual video except pass the frame through, just as trim() does. There's just the trivial overhead of determining which frame to pass.

[raffriff42]

I've heard tell ChangeFPS does some caching; maybe that's the reason it works here -https://forum.doom9.org/showthread.php?p=1473320#post1473320
ffvideosource("source.mkv")
changefps(last,last,true) # cache a few frames of input - dont ask, just do. ;-)

[tormento]

I've heard tell ChangeFPS does some caching; maybe that's the reason it works here -
Always present in my scripts. Don't ask why, I don't know :D

[LigH]

To cache explicitly, you may use RequestLinear (TIVTC.dll) (http://avisynth.nl/index.php/TIVTC); AviSynth MT also provided Preroll (http://avisynth.nl/index.php/Preroll) (or even any AviSynth v2.6+?). Does AviSynth+ offer anything similar in its kernel?

[kuchikirukia]

On a hunch, try the latest MaskTools (https://github.com/pinterf/masktools/releases/). (I've seen artifacts with 3.357 that seem to be gone now)

That's what I am using.

avs+ 2.6.0.5 ?

913,920 byte version from March 7, 2016. Reports itself as 2.6.0.5 in properties.

[raffriff42]

AviSynth+ version number is currently 2.60, the same as AviSynth. The way to tell AVS+ versions apart is with the Version & VersionString functions.
For example, the current VersionString is:
"AviSynth+ 0.1 (r2580, MT, i386)" (32-bit)
"AviSynth+ 0.1 (r2580, MT, x86_64)" (64-bit)

[LigH]

Use AVSMeter(64) to discover the version string of your currently installed AviSynth.

[ryrynz]

Or read the 'product name' line under the details tab when you right click -> properties.

[StainlessS]

This is pretty easy too
Version.avs

Version

https://s20.postimg.cc/feuqxdkgd/version.jpg (https://postimages.cc/)

[pinterf]

This is pretty easy too
Version.avs

Version


2016? Then it's time for a change.

[wonkey_monkey]

Whose site is this, which comes up as first Google result for AviSynth+?

http://avs-plus.net/

[ChaosKing]

The git link on the page links to https://github.com/pylorak/avisynth so I would assume it's ultims site aka the thread creator.

[Myrsloik]

Whose site is this, which comes up as first Google result for AviSynth+?

http://avs-plus.net/

This is funny, avs+ creators so bad at making releases the official site is forgotten...

[ryrynz]

Like I said earlier with Ultim basically out of it and with the commits that have been done long since stabilizing things it's about time things got tidied up and merged.
Need a proper version number release.

[wonkey_monkey]

I'm confused by the convertbits Wiki page:

bool truerange = true

Use the default value unless you know what you are doing.
(TODO if false, seems to either do nothing or corrupt output)
Only allowed with Planar color formats.
If true (default), convert 10-16 bit formats without re-scaling underlying pixel data. For example,
clip10bit.ConvertBits(16, truerange=false)
will leave pixel data in the 0..1023 range, but will change the color format from YUVxxxP10 to YUVxxxP16.


It says true will not "re-scale underlying pixel data" but then says false will leave pixel data in the original 10-bit range. Is this a mistake, or ambiguous terminology?

I'd also argue that "truerange" is not a good name for the parameter anyway, as it gives little hint as to what it does, either as false or true.

[poisondeathray]

I'm confused by the convertbits Wiki page:

bool truerange = true

Use the default value unless you know what you are doing.
(TODO if false, seems to either do nothing or corrupt output)
Only allowed with Planar color formats.
If true (default), convert 10-16 bit formats without re-scaling underlying pixel data. For example,
clip10bit.ConvertBits(16, truerange=false)
will leave pixel data in the 0..1023 range, but will change the color format from YUVxxxP10 to YUVxxxP16.


It says true will not "re-scale underlying pixel data" but then says false will leave pixel data in the original 10-bit range. Is this a mistake, or ambiguous terminology?

I'd also argue that "truerange" is not a good name for the parameter anyway, as it gives little hint as to what it does, either as false or true.

nice catch , it is contradictory

What would be a better "name" ? Maybe "scalerange" ?