Avisynth+

[Groucho2004]

Cough cough :)Of course there are others who spent a lot of their spare time maintaining the wiki. I was referring in particular to AVS+.

[pinterf]

It is probably related to the function syntax {DllFileName}_{FunctionName} to select a function provided by a specific DLL when several DLLs in the range of loaded plugins (especially with a full auto-load directory) provide functions of the same name. An empty DLL name may match the AviSynth core.

You may prefer a function like flipit(clip c, bool vertical) instead.
In general, when there is no dll then avs+ will simply use an empty dll name and "_" will appear as the first character in the "canonical" function name.
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/PluginManager.cpp#L209

Storing in the list using the original name
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/PluginManager.cpp#L871
Storing in the list with the canonical (in this case with the _ prefix) name
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/PluginManager.cpp#L886

This latter is overwriting the intentionally "_" prefixed _flipit function with the canonical version of flipit.

[LigH]

And I did not even read the sources... :eek: :o

[djonline]

Suggest that you change

DirectShowSource("00114.MTS-pass2-64.avs").Trim(30,0)

to

Import("00114.MTS-pass2-64.avs").Trim(30,0)



Trim not work after Import, only after DirectShowSource.

DirectShowSource("avisynth-stage1-with-MTS.avs") still not work with LAV splitter 0.71

[LigH]

Then write the Trim in a separate line, not after a dot.

If the imported script returns a clip, then it should be passed to the usual internal variable "last", which is then implicitly assumed where no explicit clip variable was written.

If it does not return any clip, then it can't be used as video source anyway.

[preludium975]

Why do I get a pink screen when I'm trying to dither 10bit -> 8bit? The source is 10bit, 4:2:0, bt.709. This is modded FFMS2, with ffmpeg decoder, but i tried all of the modded ffms2 decoders, but none of them work. I always get pink screen. LSMASH works fine, but i need FFMS2.

Here's the avs script:
FFVideoSource("sample.mkv", enable10bithack=true)
ConvertFromStacked(bits=10)
ConvertBits(bits=8, dither=0)

image (https://vgy.me/yFoB77.png)

[sneaker_ger]

Why don't you use the regular, non-modded ffms2? It supports >8 bit depths of AviSynth+ natively.

[preludium975]

I was read this, in the Avisynth‘s site: "(10-bit formats are supported with the 10bithack version - see alternate download above)"

[FranceBB]

I was read this, in the Avisynth‘s site: "(10-bit formats are supported with the 10bithack version - see alternate download above)"

Yes, in the past Avisynth+ didn't exist and regular Avisynth was working in 8bit, so 10bit+ videos were indexed as 16bit stacked (MSB at the top, LSB at the bottom).
Nowadays, Avisynth+ supports regular high bit depth, so does FFMpegSource2.
Get the latest official version of ffms2 or the latest test version of ffms2000 and index your file; ffms will automatically index it in its native bit-depth (i.e if a file is 10bit, it will be indexed as 10bit).

*if* you are using regular Avisynth and you wanna use 16bit stacked for whatever reason, then that's another story, but since you are replying in the Avisynth+ development topic, I assume you are using Avisynth+ ;)

[preludium975]

Yes, in the past Avisynth+ didn't exist and regular Avisynth was working in 8bit, so 10bit+ videos were indexed as 16bit stacked (MSB at the top, LSB at the bottom).
Nowadays, Avisynth+ supports regular high bit depth, so does FFMpegSource2.
Get the latest official version of ffms2 or the latest test version of ffms2000 and index your file; ffms will automatically index it in its native bit-depth (i.e if a file is 10bit, it will be indexed as 10bit).

*if* you are using regular Avisynth and you wanna use 16bit stacked for whatever reason, then that's another story, but since you are replying in the Avisynth+ development topic, I assume you are using Avisynth+ ;)
I tried it, it's working. But I don't need ConvertFromStacked(), because the new FFMS2 can load native 10bit, i just need the ConvertBits().

Thank you.

[Richard1485]

When converting from 10bit to 8bit with the following script...

LWLibavVideoSource("bla.mkv", stacked=true, format="YUV420P10")
ConvertFromStacked(bits=10)
ConvertBits(bits=8, dither=0)

... the luma range goes from looking like this...

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

to looking like this...

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

Have I overlooked something? When previewing in VirtualDub2, the video doesn't look obviously wrong, but I've never seen a histogram look like that unless there's a problem of some kind.

[Selur]

what happens when us use: dither = -1 ?
int dither = -1
If -1 (default), do not add dither;
If 0, add ordered dither;
If 1, add error diffusion (Floyd-Steinberg) dither doom9


Cu Selur

[Richard1485]

Yeah, I tried that. The resulting histogram still looks like the second one that I posted above.

[wonkey_monkey]

At what point in the script did you call histogram to get the first image?

It looks to me like histogram has got its levels mixed up. The graph is ostensibly the same, but there are parts where it looks like the values being plotted have overflowed - the same pattern of pixels is seen as in the "correct" image but in dark grey instead of light grey.

In fact that is exactly how it looks - if you darken the image to 0-128, then add 128 to the "blacked-out" areas, it seems to take on the correct range when comparing it to the "correct" image.

So it's like a 9-bit graph output truncated to 8-bits.

[Richard1485]

I called Histogram() when returning the video. But the first one looks fine to me. It's the second one that looks messed up.

EDIT: It's working now. I'm not sure what went wrong, but there you go.

[StvG]

ConvertBits(8) gives a big difference compared to z_ConvertFormat(pixel_type="YV12") and DitherPost(mode=-1). Is that an expected behavior?

ImageSource()
Interleave(ShowRed("y8"), ShowGreen("y8"), ShowBlue("y8")).Dither_convert_8_to_16()
Dither_convert_rgb_to_yuv (
\ SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\ matrix="709", noring=true, output="YV12", tv_range=true, chromak="spline36",
\ lsb=false, mode=6)
z_ConvertFormat(width/2,height/2,pixel_type="yuv420p16", resample_filter="spline36")
s=last
ConvertToStacked()
DitherPost(mode=-1)
a=last
s
z_ConvertFormat(pixel_type="yv12")
Compare(a, channels="yuv")

https://thumbs2.imgbox.com/5b/49/dfRSek0z_t.png (http://imgbox.com/dfRSek0z)
ImageSource()
Interleave(ShowRed("y8"), ShowGreen("y8"), ShowBlue("y8")).Dither_convert_8_to_16()
Dither_convert_rgb_to_yuv (
\ SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\ matrix="709", noring=true, output="YV12", tv_range=true, chromak="spline36",
\ lsb=false, mode=6)
z_ConvertFormat(width/2,height/2,pixel_type="yuv420p16", resample_filter="spline36")
s=last
ConvertToStacked()
DitherPost(mode=-1)
a=last
s
ConvertBits(8)
Compare(a, channels="yuv")

https://thumbs2.imgbox.com/8b/d9/pvNS1iN6_t.png (http://imgbox.com/pvNS1iN6)
ImageSource()
Interleave(ShowRed("y8"), ShowGreen("y8"), ShowBlue("y8")).Dither_convert_8_to_16()
Dither_convert_rgb_to_yuv (
\ SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\ matrix="709", noring=true, output="YV12", tv_range=true, chromak="spline36",
\ lsb=false, mode=6)
z_ConvertFormat(width/2,height/2,pixel_type="yuv420p16", resample_filter="spline36")
s=last
ConvertBits(8)
a=last
s
z_ConvertFormat(pixel_type="yv12")
Compare(a, channels="yuv")

https://thumbs2.imgbox.com/99/54/Pq5DIzXm_t.png (http://imgbox.com/Pq5DIzXm)

Image source (https://images2.imgbox.com/9c/a8/TusqdQS0_o.png).

[wonkey_monkey]

Is there any way to get a debug output of the compiled code generated when using expr()?

[pinterf]

Is there any way to get a debug output of the compiled code generated when using expr()?
No, I put a breakpoint at the entry of calling the compiled code and then changed to assembler view.

[wonkey_monkey]

Okay. Such a facility would be nice if you ever happen to be near that code again :)

[Richard1485]

I've experienced for the second time the same problem that I raised in post#4261. If I switch from the x64 version of ffms2 to the x86 one, it goes away. This must have been why the issue suddenly seemed to clear up (for which, see post#4265): both times, I switched versions (for unrelated reasons). I just didn't put two and two together. Does anyone experience this issue or is it just me?

[poisondeathray]

I've experienced for the second time the same problem that I raised in post#4261. If I switch from the x64 version of ffms2 to the x86 one, it goes away. This must have been why the issue suddenly seemed to clear up (for which, see post#4265): both times, I switched versions (for unrelated reasons). I just didn't put two and two together. Does anyone experience this issue or is it just me?

I can reproduce this.

Either ffms2 or lsmash as your earlier post

avsresize to convert bits instead of convertbits also same result

I don't have avs+ 86 installed , so I can't check that or x86 source filters . But if it "goes away" with ffms2 x86, then it suggests avisynth+ x86 histogram is not affected

vpy x64 version of histogram not affected


EDIT: I just rechecked some things and I can NOT reproduce it anymore! I have no idea what is going on but I'm sure I saw it earlier

[pinterf]

I called Histogram() when returning the video. But the first one looks fine to me. It's the second one that looks messed up.

EDIT: It's working now. I'm not sure what went wrong, but there you go.
If my assumption is right, the problem depends on special timing conditions so it's not 100% reproducible, and is inside Avisynth.
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/histogram.cpp#L1600
The brigtness lookup table may not always be initialized fully by the time it is used in another thread. I could reproduce such effect by inserting an artificial sleep
std::this_thread::sleep_for(std::chrono::milliseconds(1));
inside the for-loop of lookup (here: variable exptab) generation.

Looking at the code of the Classic histogram I noticed another problem. Since there is only a single predefined lookup table, it will be calculated for whatever bit-depth is found first.
When classic histogram appears e.g. twice for different bit-depth they won’t work properly for both instance. Just check it:
...some 8-bit clip here...
x8 = last
x16 = last.ConvertBits(16)
StackVertical(x16.Histogram().ConvertBits(8),x8.Histogram())
I'll check both problems.

[StainlessS]

Hi P, hows bout an Avisynth_+_Pinterf thread, about time you had thread control.

Just point one last post pointing at new thread (with request for no new posts unless directed at Ultim original branch).

[tormento]

Strange internal filter error here (https://forum.doom9.org/showthread.php?p=1856262#post1856262).

Any hint? Latest AVS+ installed.

[LigH]

The expression "latest" is insufficient. Please tell us the exact version (e.g. via AVSMeter).

The latest release of AviSynth+ MT by pinterf (https://github.com/pinterf/AviSynthPlus/releases) is r2728-MT (20180702).

[tormento]

The expression "latest" is insufficient.
I use the latest release version. The one you quoted, x64 flavor. :D

[Groucho2004]

I use the latest release version. The one you quoted, x64 flavor. :D
Run "avsmeter64 avsinfo" and check if that throws any error(s).

[tormento]

Run "avsmeter64 avsinfo" and check if that throws any error(s).
AFAIK no error:
AVSMeter 2.8.6 (x64) - Copyright (c) 2012-2018, Groucho2004

VersionString: AviSynth+ 0.1 (r2728, MT, x86_64)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 5
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SYSTEM32\avisynth.dll
Avisynth.dll time stamp: 2018-07-02, 12:54:16 (UTC)
PluginDir2_5 (HKLM, x64): D:\Programmi\Media\AviSynth+\plugins64
PluginDir+ (HKLM, x64): D:\Programmi\Media\AviSynth+\plugins64+


[CPP 2.6 Plugins (64 Bit)]
D:\Programmi\Media\AviSynth+\plugins64+\FFT3dFilter-2.5-pinterf.dll [2.5.0.0]
D:\Programmi\Media\AviSynth+\plugins64+\GamMac-1.10.dll [1.10.0.0]
D:\Programmi\Media\AviSynth+\plugins64+\KNLMeansCL-1.1.1.dll [2018-01-29]
D:\Programmi\Media\AviSynth+\plugins64+\MaskTools-2.2.18-pinterf.dll [2.2.18.0]
D:\Programmi\Media\AviSynth+\plugins64+\MVTools-2.7.32-pinterf.dll [2.7.32.0]
D:\Programmi\Media\AviSynth+\plugins64+\RgTools-0.97-pinterf.dll [0.97.0.0]
D:\Programmi\Media\AviSynth+\plugins64+\ZLlib-r1d-Savage.dll [2018-03-22]

[Scripts (AVSI)]
D:\Programmi\Media\AviSynth+\plugins64\CompTest.avsi [2010-09-05]
D:\Programmi\Media\AviSynth+\plugins64\SMDegrain-3.1.2·100.avsi [2018-07-11]
D:\Programmi\Media\AviSynth+\plugins64\TemporalDegrain-2.1.1-ErazorTT.avsi [2018-10-27]

[Uncategorized DLLs (64 Bit)]
D:\Programmi\Media\AviSynth+\plugins64+\libfftw3f-3.dll [2018-10-24]

[Uncategorized files]
D:\Programmi\Media\AviSynth+\plugins64+\AviSynth-new.css [2016-03-31]
D:\Programmi\Media\AviSynth+\plugins64+\AviSynth.css [2016-03-31]
D:\Programmi\Media\AviSynth+\plugins64+\FFT3dFilter-2.5-pinterf.htm [2018-07-06]
D:\Programmi\Media\AviSynth+\plugins64+\FFT3dFilter-2.5-pinterf.md [2018-07-02]
D:\Programmi\Media\AviSynth+\plugins64+\FFT3dFilter.gif [2005-04-04]
D:\Programmi\Media\AviSynth+\plugins64+\GamMac-1.10.txt [2018-06-15]
D:\Programmi\Media\AviSynth+\plugins64+\KNLMeansCL-1.1.1.htm [2018-03-10]
D:\Programmi\Media\AviSynth+\plugins64+\MaskTools-2.0a48.htm [2010-12-31]
D:\Programmi\Media\AviSynth+\plugins64+\MaskTools-2.2.18-pinterf.md [2018-09-05]
D:\Programmi\Media\AviSynth+\plugins64+\MVTools-2.7.32-pinterf.htm [2018-10-18]
D:\Programmi\Media\AviSynth+\plugins64+\MVTools-2.7.32-pinterf.md [2018-10-18]
D:\Programmi\Media\AviSynth+\plugins64+\RgTools-0.97-pinterf.md [2018-07-02]
D:\Programmi\Media\AviSynth+\plugins64+\ZLib-r1d-Savage.md [2016-10-30]
D:\Programmi\Media\AviSynth+\plugins64\AviSynth-new.css [2016-03-31]
D:\Programmi\Media\AviSynth+\plugins64\AviSynth.css [2016-03-31]
D:\Programmi\Media\AviSynth+\plugins64\SMDegrain-3.1.2d.htm [2015-07-21]
D:\Programmi\Media\AviSynth+\plugins64\Stab-256.1.01-videoFred.7z [2018-09-04]

[StainlessS]

No help here but get rid of all the uncategorised files from plugs, they are all not needed there, ie rubbish.

No sure if ok to have libbfft3d-3.dll where it is (think some plugs were altered to also scan same dir as plugin).
(I would probably put mine in system32, although if using both 32 and 64 bit together, then I think things change,
not sure, have to check that out when I go that way)

[Groucho2004]

AFAIK no error
Weird. Run the script with avsmeter64.

[tormento]

Weird. Run the script with avsmeter64.
AVSMeter 2.8.6 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Script error: There is no function named 'ConvertToStacked'.
(D:/Programmi/Media/AviSynth+/plugins64/TemporalDegrain-2.1.1—ErazorTT.avsi, line 236)
(E:\in\2_01 sacrificio del cervo sacro, Il\sacrificio_4td.avs, line 17)

[tormento]

No help here but get rid of all the uncategorised files from plugs, they are all not needed there, ie rubbish.
Usually I have no problems. :(
No sure if ok to have libbfft3d-3.dll where it is
It's ok with Pinterf's build.

[LigH]

Does your script or any imported script explicitly load a plugin DLL from a separate directory, which might be obsolete?

[Groucho2004]

There is no function named 'ConvertToStacked'This error really has me stumped since you have the correct Avisynth version and seemingly all necessary dependencies installed. :confused:

[Groucho2004]

This error really has me stumped since you have the correct Avisynth version and seemingly all necessary dependencies installed. :confused:

Stupid me. ConvertToStacked is an external plugin function and none of the AVS+ plugins - one of which is ConvertStacked.dll - show up in the log.

tormento, put the AVS+ plugins into your auto-load directory.

[Richard1485]

I'll check both problems.

Thanks! I appreciate your looking into this.

[edcrfv94]

trim(??, ??)
#e.g trim(71152, 72152)
SelectEvery (1, -7, -6, -5, -4, -3, -2, -1, 0, 1, 2, 3, 4, 5, 6, 7)


the 0-6 frames will come from before trim 71152 and have some unnecessary frames at end.
correct should be repeat first frames 7 times and total frames 1001*15 = 15015.

[pinterf]

Strange internal filter error here (https://forum.doom9.org/showthread.php?p=1856262#post1856262).

Any hint? Latest AVS+ installed.
There should be a ConvertStacked.dll in the plugins+ or plugins64+ folder
Edit: Groucho2004 was quicker, I should have scrolled down a bit.

[tormento]

Stupid me. ConvertToStacked
We are both. I assumed, since internal, it was incorporated into avisynth.dll code.

Thanks. Pinterf too. :)

@pinterf: is there any specific reason you keep on carrying those "internal" filters as external dll instead of incorporating them?

[pinterf]

We are both. I assumed, since internal, it was incorporated into avisynth.dll code.

Thanks. Pinterf too. :)

@pinterf: is there any specific reason you keep on carrying those "internal" filters as external dll instead of incorporating them?
It's by design which was decided by ultim and co. We put stacked conversion support in avisynth+ for convenience, even considered they exist only temporarily. I couldn't foresee that so much plugins working in stacked format will freeze in development and still exist years after the native high bit depth support.

[pinterf]

Hi P, hows bout an Avisynth_+_Pinterf thread, about time you had thread control.

Just point one last post pointing at new thread (with request for no new posts unless directed at Ultim original branch).
I guess thread control means editing the very first post. Good idea, considering.

[tormento]

It's by design which was decided by ultim and co.
AFAIK the one and only who keeps project alive is you. IMHO we don't need to walk into another cul de sac, like plain AVS did: it's better to understand that evolution is the right way to go. You did great things such as high bitdepth support, etc. It's time that, without jumping onto VS vagon, things shoud have the freedom to grow with their legs. :o There are other forums where some filters has started to share CUDA space to have some speedup. I honor the ancestors but I appreciate much more who spends time to keep the project alive.

[StainlessS]

@tormento,
:goodpost:

[tormento]

@pinterf

I wrongly addressed to LoRd_MuldeR the fault for Simple x264/265 launcher not giving Unicode log. I am aware now that is probably AviSynth the one not compliant :)

Can you tell me if it's Unicode aware or not in the error messages at least?

[pinterf]

No unicode. Utf8 is supported in Import file path and name, and Subtitle text through an extra utf8 bool parameter

[tormento]

No unicode. Utf8 is supported in Import file path and name, and Subtitle text through an extra utf8 bool parameter
Would be a nightmare to implement in error messages?

[StainlessS]

Dont know if this is a bug in avs+ or not.

https://forum.doom9.org/showthread.php?p=1857024#post1857024

[pinterf]

Dont know if this is a bug in avs+ or not.

https://forum.doom9.org/showthread.php?p=1857024#post1857024
Memory is eaten? We are going to know it in the near future.

[StainlessS]

Memory is eaten?

Yep.
With my test clip (854x480@30, 3775 Frames), memory usage max's out at about 1.73GB,
but when reaching end and then traversing backwards, we get this

https://i.postimg.cc/zyJfV6f9/OMEM.jpg (https://postimg.cc/zyJfV6f9)

EDIT: Win7 x64 with 12GB DDR3 (avs+ x86).

EDIT: If opening clip in VD2, and jumping to last frame, then traversing backwards a 1000 or so frames, all is ok,
but on swap direction and going forwards, then will OMEM again.
EDIT: Test clip is UT_Video YV12 avi.

[pinterf]

Yep.
With my test clip (854x480@30, 3775 Frames), memory usage max's out at about 1.73GB,
but when reaching end and then traversing backwards, we get this

EDIT: If opening clip in VD2, and jumping to last frame, then traversing backwards a 1000 or so frames, all is ok,
but on swap direction and going forwards, then will OMEM again.
EDIT: Test clip is UT_Video YV12 avi.
For me it was all the same whether I used classic avs or avs+. That this specific memory size of around 1700MB was making either x86-virtualdub2 itself or the frame allocation inside avisynth to crash.

E.g. when I set memory max to 64 (which is the minimum in avs+) the internal frame caches of avs+ core were more or less keeping that limit, while the total memory consumption was way larger.

Avisynth is not able to count in the actual allocation habits of the loaded dlls and filters. In this case probably the biggest memory consumer was MFlowInter in MvTools2 (which I have optimized a bit - see mvtools2 topic). And perhaps other filters were also contributing to such memory scenario that full allocation is around 1700MB but avisynth core itself used less than 200MB.

Anyway I continue investigating the issue because I do not understand why pulling the slider back and forth still makes the script in vdub2 consume more and more memory. For earlier tests memory (task manager) still seemed to grow, though the script contained a single AviSource line.