[Neo] f3kdb

[kedautinh12]

New commits, can anyone compile it??
https://github.com/HomeOfAviSynthPlu...tion/neo_f3kdb

[l00t]

Originally Posted by kedautinh12

New commits, can anyone compile it??
https://github.com/HomeOfAviSynthPlu...tion/neo_f3kdb

You can get it from Asd-g's plugin pack: https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts

[kedautinh12]

Thanks

[GMJCZP]

Originally Posted by kedautinh12

Thanks

But is there the r7 version?

[kedautinh12]

No, it's new compile 20 hours ago. It's still r6 but added new commits by asd-g

[StvG]

It's r7.

[kedautinh12]

Oh, my mistake, sr

[kedautinh12]

New ver neo-f3kdb
https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts

[GMJCZP]

Originally Posted by kedautinh12

New ver neo-f3kdb
https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts

Thanks. Although it says that it is also an r7 version, the size is larger than the previous r7 version (282 kb against 224 kb).

[real.finder]

Originally Posted by GMJCZP

Thanks. Although it says that it is also an r7 version, the size is larger than the previous r7 version (282 kb against 224 kb).

if you use avs then you don't need to update anyway, the update is for vs only (there was bug in vs case)

[almosely]

Hideho,

me, again ;-)

Recently I installed Release 7 and used it with mt=true for a few encodings without problems.

But my latest encoding crashed at around 30% with mt=true and at around 60% with mt=false. Now I re-installed Release 6 and the encoding finished without problems.

My hardware:

- Intel Core i7-3770

- ASUS GTX660 TI

- 16 GB DDR3 SDRAM

My software:

- Windows 10 Pro 20H2 64-Bit

- Simple x264/x265 Launcher 64-Bit (2021-05-29)

- AviSynth+ 3.7.0 64-Bit

- L-SMASH-Works (2021-04-23) 64-Bit

- TIVTC 1.0.26 (22-02-2021) 64-Bit

- neo_f3kdb r6 (30-05-2020) 64-Bit (working)

- neo_f3kdb r7 (05-07-2021) 64-Bit (not working)

My AVS-script (used that script for about one year without problems):

SetCacheMode(1)

LWLibavVideoSource("Movie.mkv", format="YUV420P8", prefer_hw=1)

RequestLinear(rlim=200, clim=200, elim=100)

Crop(0, 138, -0, -138)

Spline64Resize(1280, 536)

Prefetch(4,8)

sharpen(0.128)

Prefetch(4,8)

neo_f3kdb(range=15, y=48, cb=48, cr=48, grainy=0, grainc=0, dither_algo=2)

Prefetch(4,8)

return last

My x265-parameters within Simple Launcher for nearly all 720p-encodings for about a year:

Encoder: x265 (HEVC)
Architecture: 64-Bit (x64)
Variant: 8-Bit
Rate Control: CRF
Quantizer/CRF: 17,0
Preset: medium
Tune: <None>
Profile: <Unrestricted>

Custom Encoder Parameters:

--no-open-gop --selective-sao 1 --lookahead-slices 1 --ref 5 --bframes 4 --weightb --rc-lookahead 40 --me 3 --subme 4 --max-merge 4 --hevc-aq --rd 4 --rdoq-level 2 --psy-rd 4.5 --psy-rdoq 8.0 --ctu 32 --merange 26 --keyint 240 --sar 1:1 --pools 8

I tested and refined these encoding (and AVS-script) settings a few weaks and tried nearly every x264 and x265 parameter (and resize and sharpening method for 1080p to 720p), checked with my eyes and FFMetrics, tuned for quality, speed and compatibility. These settings replaced my old x264 crf 17 settings as followed:

Quantizer/CRF: 17,0
Preset: slower

--rc-lookahead 40 --threads 13 --me umh --subme 10 --merange 24 --deblock -1:-1 --psy-rd 1.0:0.15 --aq-strength 1.0 --bframes 5 --ref 5 --keyint 240 --aq-mode 3 --sar 1:1

and:

Quantizer/CRF: 18,5
Preset: slower

--rc-lookahead 80 --threads 18 --me umh --subme 10 --merange 32 --deblock -1:-1 --psy-rd 1.0:0.15 --aq-strength 1.0 --bframes 5 --ref 9 --keyint 240 --aq-mode 3 --sar 1:1 --non-deterministic

(both with BlackmanResize within AVS, without sharpening).

So, for me, r7 is not working.

[Boulder]

Remove all those extra Prefetch lines and leave just one there as the last item of your script. You also do not need "return last" at all.

[almosely]

Originally Posted by almosely

I tested and refined these encoding (and AVS-script) settings a few weaks and tried nearly every x264 and x265 parameter (and resize and sharpening method for 1080p to 720p), checked with my eyes and FFMetrics, tuned for quality, speed and compatibility.

I used to set only one "Prefetch(x)" at the end of my scripts before AviSynth got the update to handle multithreading differently ("Prefetch(x,y)").

Setting "return last" seems to be a question of faith, hm?

[kedautinh12]

Updated r8:
https://github.com/HomeOfAviSynthPlu...f3kdb/releases

[PoeBear]

Originally Posted by kedautinh12

Updated r8:
https://github.com/HomeOfAviSynthPlu...f3kdb/releases

What are the use cases of the new parameters: Y2, Cb2, Cr2?

[ChaosKing]

Source code says: `Y`, `Cb`, `Cr` are internally left shifted by `2` while `Y2`, `Cb2`, `Cr2` - by `5`.

[Julek]

Originally Posted by PoeBear

What are the use cases of the new parameters: Y2, Cb2, Cr2?

https://github.com/HomeOfAviSynthPlu...omment-3592269

[PoeBear]

Originally Posted by Julek

https://github.com/HomeOfAviSynthPlu...omment-3592269

What are the use cases though? Ie, what types of sources would we want to use the new parameters vs the old parameters? Were there issues/limitations with the old parameters, is it an 8 vs 16-bit thing, should we always use the new ones going forward, etc?

[Greenhorn]

Originally Posted by PoeBear

What are the use cases though? Ie, what types of sources would we want to use the new parameters vs the old parameters? Were there issues/limitations with the old parameters, is it an 8 vs 16-bit thing, should we always use the new ones going forward, etc?

Stronger debanding, I guess. y/cb/cr are limited (and normalized, so they're ~the same regardless of bitdepth) to the range of 0-511, and this appears to allow circumventing that limitation without rewriting whatever code causes it-- "y=0,y2=64" produces seemingly the exact same output as "y=511,y2=-1", and debanding strength continues to get stronger as you increase y2 past 64.

I'm not sure how practical this actually is, but I guess this is meant to make f3kdb more competitive with other inherently stronger filters for really really messed up videos.

[kedautinh12]

Originally Posted by Greenhorn

Stronger debanding, I guess. y/cb/cr are limited (and normalized, so they're ~the same regardless of bitdepth) to the range of 0-511, and this appears to allow circumventing that limitation without rewriting whatever code causes it-- "y=0,y2=64" produces seemingly the exact same output as "y=511,y2=-1", and debanding strength continues to get stronger as you increase y2 past 64.

I'm not sure how practical this actually is, but I guess this is meant to make f3kdb more competitive with other inherently stronger filters for really really messed up videos.

Y2, Cb2, Cr2 (> r7)

When specified respectively Y, Cb, Cr do not have effect