Internaly multi-threaded resampling functions

[jpsdr]

New version, see 1rst post. I'll not say final, because there may be update in the functions of the core in the future i'll try to follow, but for now, i think i'm done with the threadpool part.

[jpsdr]

Never said "At last, final version"...
New version, see 1rst post.

[bilditup1]

With latest avs+ mt r2172 & your nnedi3 r26, using this yields a 1.5fps increase using this script on a (for now) stock 4770K. Sometimes the encode appears to halt entirely but I'm not sure if this is an avs+ issue or a ResampleMT/nnedi3 issue.

[jpsdr]

New version, see first post.
I've added several parameter to allow to tune the created threadpool. I've made several testbench, and set the default settings correspond to the best result i have on my PC. But, it doesn't mean it will be also what produce the best result on others PC, so, the parameters added will allow to eventualy each one tune according his hardware configuration.

Check the ReadMe file for precise information.

[real.finder]

I did edit to ResizeX to make it work with this plugin

edit : add edi_rpow2_v1.0.zip and maa2

new edit ResizeX and edi_rpow2 will work in new avs+ colour format

edit: another ResizeX edit here https://forum.doom9.org/showpost.php...45&postcount=5 and use it with this https://pastebin.com/8kcg2MtJ edi_rpow2

[jpsdr]

New version (see 1rst post).
Can be used also with prefetch without issue, and can also be used with the last nnedi3 version and with prefetch also.

[jpsdr]

New version, see first post.

[real.finder]

I wonder how this filter work, it's depends on avs Resizers or have an edit of them?

I ask because I didn't see any mention on what colour format that this filter supports

[jpsdr]

It uses the code of the internal avs+ resamplers. About supported format, it supports all the formats supported by avs+ at the time the filter has been build.
I'm working on the new version to support the new formats, but for now it crashes in both avisynth and avs+ and i don't had time to investigate futher. But i'll probably be able to resume work on it soon.

[real.finder]

Originally Posted by jpsdr

It uses the code of the internal avs+ resamplers. About supported format, it supports all the formats supported by avs+ at the time the filter has been build.
I'm working on the new version to support the new formats, but for now it crashes in both avisynth and avs+ and i don't had time to investigate futher. But i'll probably be able to resume work on it soon.

after I update to last ResampleMT and NNEDI3 from ResampleMT 1.0.2 and NNEDI3 0.9.4.24 I see speed lost, from 1.6 fps to 1.3 fps, is this because threadpool?

why not try using avstp?

and can z.lib make it faster?

[jpsdr]

Originally Posted by real.finder

after I update to last ResampleMT and NNEDI3 from ResampleMT 1.0.2 and NNEDI3 0.9.4.24 I see speed lost, from 1.6 fps to 1.3 fps, is this because threadpool?

Honestly, i don't know, but it's not impossible, even more possible if you're also multi-threading again using prefetch. Is it the case ?
As there is only one threadpool shared instead of several (before, one was created for each instance filter) => result in slowdown when shared resources required.
For optimal, i suggest if you're also prefetching to reduce the number of threads and make tests. The values i suggest for testing are first threads=1, and second threads=CPU/2. And if you're using ResampleMT within NNEDI3, don't forget also to put the value on the threads_rs parameter.

Originally Posted by real.finder

why not try using avstp?

Not interested, and using an external dll for the threadpool make it even slower (i've tested with my threadpool).

Originally Posted by real.finder

and can z.lib make it faster?

No idea. But if it uses directly a square kernell instead of doing two passes, multi-threading by splitting the image may be more difficult.

[jpsdr]

New version, check first post.

[jpsdr]

New version, check first post.

[jpsdr]

New version, check first post.

[real.finder]

  range -
      This parameter specify the range the output video data has to comply with.
      Limited range is 16-235 for Y, 16-240 for U/V. Full range is 0-255 for all planes.
      Alpha channel is not affected by this paramter, it's always full range.
      Values are adjusted according bit depth of course. This parameter has no effect
      for float datas.
      0 : Automatic mode. If video is YUV mode is limited range, if video is RGB mode is
          full range, if video is greyscale (Y/Y8) mode is Y limited range.
      1 : Force full range whatever the video is.
      2 : Force limited Y range for greyscale video (Y/Y8), limited range for YUV video,
          no effect for RGB video.
      3 : Force limited U/V range for greyscale video (Y/Y8), limited range for YUV video,
          no effect for RGB video.

      Default: 0

do we really need this? we can do it in avs Limiter if we have to, but having range in resize or nnedi make no sense and if someone work in full range will have to set it to 1 every time, and it's kinda annoying

[jpsdr]

I don't agree, standard YUV is not full range, so it results that nnedi and resize can produce incorrect value output. On the oposite, someone who want to work with standard value has to put a limiter...?
No, that's not a proper behavior for me, it's the contrary, you have to specify "something" when you want to work outside standard values.

[real.finder]

Originally Posted by jpsdr

I don't agree, standard YUV is not full range, so it results that nnedi and resize can produce incorrect value output. On the oposite, someone who want to work with standard value has to put a limiter...?
No, that's not a proper behavior for me, it's the contrary, you have to specify "something" when you want to work outside standard values.

and what about scripts that do everything with Y8? at least you should make the default is 3 for Y/Y8 so that chroma will be correct ((if there is RGB support (by Y8 is scripts) then it will fall, but I don't care for RGB, if you care then Y/Y8 should have range default 1)), for both nnedi and this

edit: and scripts that did TV to PC range internally for some specific purpose like SMDegrain will fall too, so default should be 1 everywhere, that reminds me of keep_tv_range bool in flash3kyuu_deband, it's false by default

[jpsdr]

Originally Posted by real.finder

at least you should make the default is 3 for Y/Y8 so that chroma will be correct

But luma will not be, so...

Originally Posted by real.finder

edit: and scripts that did TV to PC range internally

A script/plugin can do whatever it wants internaly, it have to put back correct levels on its output, otherwise, it screws you things without telling you.

Originally Posted by real.finder

keep_tv_range bool in flash3kyuu_deband, it's false by default

Yes, it should be the oposite, when i use it on YUV data, i always have to put it to true.

[real.finder]

Originally Posted by jpsdr

A script/plugin can do whatever it wants internaly, it have to put back correct levels on its output, otherwise, it screws you things without telling you.

it do tv to pc for motions search for example, your change will make that fall or useless

anyway, I will stick with the older versions, thank you for the old change efforts it was cool

[jpsdr]

Originally Posted by real.finder

it do tv to pc for motions search for example, your change will make that fall or useless

You just have now to specify that range is not anymore the standard range for the actual format, and it will not break anything.
Of course, if a metadata tag existed, it would have been perfect...