Assistance with StaxRip

[Kevin_san]

nnedi3 sounds interesting.
Is it the one with the 13MB pattern database? Perhaps I should try it. But it is still bobbing?
About the canvas ringing, I wonder how this can have any relevance, nothing to see there.
The asymmetric kernel needs a shift, so internally there is a canvas to add left and below, and then to remove.
I would know what to do, some extra canvas that mirrors the data for 6px to the outside, so the convolution can't catch any edges there to carry around.
If you know a canvas plugin that does mirror instead of plain black or grey, I would include it. Scripting it might be slower and a nuisance.

For the thousands of mp4s in the wild that are blurred like hell, I am really happy with my own, that are almost lossless if I like it so.
So I don't object if I really like the girl. She can have a mole and the canvas can have ringing, and a free video can have a little blur, but that's just what I think.

The bobbing is pretty nostalgic, but the general resolution will prevent many young viewers from watching anyway, even when all traces of that are removed.
My parents had a very good B&O CRT TV, I know how it looks in the analog world.

So what I am attempting is to get that stuff a bit more glossy, instead of noisy, BR 4k to compare aren't noisy, and also steal a bit more of detail from between the pixels, as you see above. There is a theory for this.
((you can cheat Nyquist to some extent when patterns repeat, or when there is soft blur that is mathematically clean. you can't exactly restore the original but the neighbor pixels carry information scattered from surroundings, that is not quantized to a pixel position of its origin, lense errors are analog, and we can collect this and it will contribute a little bit.))
The bobbing preserves a little bit more detail than QTGMC can do, but it can be noise or be distorted as well. Depends on the compression factor in the mpeg2.

I would recommend to execute the scripts, would be glad to upload this one, it takes Avidemux and changing like 4 paths, =source file, also in the included d2v, and =yadif path, also dgdecode if not found and it has 2 versions, because some ISOs work only with the older decoder version.
Results can be felt only with playing the video, and getting used to it for a minute. In a dark room, it feels like a window, not like a digital screen. Very 3-dimensional, while to my eyes, most QTGMC results look a bit flat and boring. So currently we are a handful of people with different taste, but I would be excited to know if there are downloaders that like the style. But I am not an uploader, I leave everything to the one who does the operative.

 

[Porni]

The bobbing is pretty nostalgic, but the general resolution will prevent many young viewers from watching anyway, even when all traces of that are removed.

Young pay a lot of $ on onlyfans for shitty selfies

My parents had a very good B&O CRT TV, I know how it looks in the analog world.

I like to see such a difference for old games

 

[Kevin_san]

yeah you totally got it. though since XP or something there is a technology in the screen drivers that adjusts "font hints" into detailed control of the 3 color panes, and they had an adjustment applet so you could adapt to your particular LCD screen. this was a huge thing so the people became less tired when writing stuff on the computer.
you know about apple ][ and how it made colors for games? now that was bizarre fun. I know a guy who could build TV HF interfaces for this.

 

[SamKook]

Most if not all deinterlacers interpolate the missing data between the lines to prevent bobbing when played back as progressive, with varying degrees of precision. You can read more about each deinterlacer details on the avisynth wiki: http://avisynth.nl/index.php/Category:Deinterlacers

The canvas ring would bother me personally, but if you're fine with it, it's up to you.
You can use a combination of FlipHorizontal/Vertical, Crop and StackHorizontal/Vertical to mirror and expand the edges and do another crop to remove the excess once you're done with it.

Never had much success making something I think looks good using your avidemux scripts from a few years back. Yadif shimmers way too much for my taste in places, that's why I always use qtgmc.

 

[Kevin_san]

thx for feedback, it has come a long way since then.
main problem for reuse is to understand the numeric language of the kernel. for anyone else it will be hard to know which kernel should be used for a new attempt.
I became a bit better in this. there are over a hundred settings available, the newer ones look a bit different.
- one big difference is that avidemux got the denoising parameter.
some scenes are shimmering, but after more experimenting, this looks closer to interlaced TV.
after looking it up again in their wiki, I see why we do different things. nnedi3 if used, throws away the other field. this is loss of resolution, and it may be the reason that I am not excited about some QTGMC encodes, and thus tried something entirely different.
- the other innovation is the luma pre-blending, to compensate for wrongful sharpening of the interlaced stream at the producer's site.
this also needs to be fine tuned, but then it can improve the symmetry in the deinterlacing between the fields. ants are still running, but centered to the object, which helps the denoiser to flatten it out a bit, and also I found out that my windows tablet has very nice smoothing algorithms in the driver, and mitigates the shimmer even more.
so the tricky thing is for me, to merge the shimmer with shimmering original details, and make the original crispy, so it dominates over the shimmer.
funny two aspects: it has analog TV shimmer/bobbing, but it also looks a tiny bit like video game rendering, depending on the source material. it is a little bit superreal and psychedelic, but subtle enough to watch regularly, for me to appear as the new normal. it respects the art of the camera man well, but as a medium it is idiosyncratic, it has a look nowhere else seen.

I was expecting innovation in yadif, but the only thing was edeint prediction input, but I don't understand how this works. is this what QTGMC is doing?
If one lets run a different deinterlacer in parallel, then from there, fed into yadif, it could make the prediction about the running ants, ie. which pixel is the object and which is the empty space, when it is in the limbo at a 1-2px-wide gap.

(did you ever run a test whether the x264 in Avidemux is a normal version? I'm on 2.7.0. it is hard to prevent it from blurring results. therefor I started the upscaling, but then found a lot of other benefits in this. I don't claim the content gets upscaled, but it gets thrown into a different grid. there is more room for better filtering, and there is no room for the normal staircase artifacts. most ideas come from audio DSP tech.)

I should try the canvas repair, thx for the suggestions, let's see.... (but they do flip the whole frame which is very inefficient, I must in advance crop what I need and then flip.)
got to figure out the stacking.

 

[SamKook]

I couldn't tell you exactly what QTGMC does, I never looked over the script in details to understand it all.
You can read the description for TempGaussMC, QTGMC is a faster version of that, it's short for Quick TempGaussMC.

Avidemux uses ffmpeg and ffmpeg uses x264 so yeah, it's standard. It would be a different h264 encoder if it weren't.
I did notice messing around with x265 this past week that I get a less blurry result than my previous x264 settings. Probably not an option for you since it does take 5-6 times longer to encode on my pc even after optimizing the multithreading but it case you wanna mess around, I've settled on these settings:

--preset veryslow --tune grain --ctu 32 --pmode --merange 26 --psy-rdoq 3.00 --psy-rd 3.0 --crf 21

The result is sometimes bigger than x264 with those, but if you use 22 for the crf, it'll be smaller and still less blurry. The --pmode is only useful if your cpu isn't maxed already, otherwise it just hurts performance and does nothing else but since I have 16 cores, it's very useful to me.

Yeah, you can easily crop before the flip and stacking is very simple, takes 2 clip as parameters and puts them aside each other in order, left to right and top to bottom.

 

[Porni]

However, h265 is not designed for SD and without fine-tuning the result is bad.

 

[SamKook]

The "--tune grain" is essential for sd or it's a blurry mess(my smaller mp4 encodes have it disabled and are at the default crf 28 since the point is for it to be very small) even at much higher bitrate. Haven't noticed any ill effects so far with that on and the psy-rdoq can be tuned a bit for more or less grain preserving and psy-rd too but less reasons to touch that one.

ctu 32 and merange 26 (both lower than the defaults) I don't think have a negative impact for quality at the default, but it's not useful unless the source is 4k. Could maybe be lowered even more since those settings are fine for 1080p, but I tuned those for my cpu to be able to work more and that low is enough.

 

[Porni]

And what ends up being the same as "libx264 -crf 19 -preset slower -tune film" but "it does take 5-6 times longer to encode"?

 

[Porni]

For example, about the "wonderful" h265 presets:

Sao, for example, is needed only at super-low, cutree on grain and best in conjunction with rect and tskip + aq3, while all presets do not have it and rect and tskip are disabled by default. Because everything is geared to a smaller size relative to 264 at any cost. The same sao is a filter that does a good job of removing artifacts at ultra-low bitrates, but it is included in almost all presets and will just cause loss of fine details in images where it is not needed.

 

[SamKook]

It looks better than my crf 18 preset veryslow -tune film. If it were the same I'd have stuck with x264.

And yeah, sao is bad, the grain tuning disables it: https://x265.readthedocs.io/en/master/presets.html#tunings

 

[Porni]

grain tuning

Try disabling sao and using cutree and rect without tune

It looks better than my crf 18 preset veryslow -tune film

I do not understand, only if it is an old film video with a lot of noise, otherwise "crf 18 preset veryslow -tune film" is a visual lossless.

 

[SamKook]

If you look close enough, it's not visually lossless but the difference is not very big. I have some comparison screenshots for FTBD-036, both look very good to me but the x265 one is mostly closer to the dvd than x264, depending on where you look, but during playback, I doubt you'd notice:
x264:

ISO:

x265:



It becomes more apparent when the source is noisier though, the comparison I did for LPFD-214 shows the x264 version to be softer than the x265 one with the same qtgmc and other settings: https://www.akiba-online.com/thread...shinoaki-felony-sentence.2093181/post-4566074


I'll mess around with those settings instead of grain and see how it compares.

 

[SamKook]

A good example from the FTBD comparison above is the right shoulder. x264 on the left, dvd in the middle and x265 on the right. You can see the beauty mark/pimple is gone in x264 but not in x265.
Original size:

3x:


Didn't notice before how much smoother the x265 version is though in that 3x zoom, but the result is better. Probably explains why that screenshot compresses more than x264 even though the whole video is bigger with x265.

 

[Porni]

A good example from the FTBD comparison above is the right shoulder. x264 on the left, dvd in the middle and x265 on the right. You can see the beauty mark/pimple is gone in x264 but not in x265.

Timing?

 

[SamKook]

00:39:20.760

 

[Porni]

Yes, hardly noticeable.
Only size 265 is bigger and can compare with 264 crf 16 and crf 18 -tune grain


Still, encoding time of 5-6 longer is a terrible overkill compared to the result

 

[SamKook]

The size is only bigger if you use crf 21 and it depends on the source, the noisier LPFD-214 ended up smaller. At crf 22, the size goes down to 1.10GB instead of 1.31GB(my x264 rip was 1.25GB), is a little faster and it still looks better than x264.
x265 crf22:


Since I preferred the result of 21, I went with that since the increase in size doesn't bother me and it's still reasonable. Going up to 20(didn't do a full movie rip of that one so don't know the size) wasn't worth it and I also tried 21.5 which ended up being 1.19GB but 21 was better.

I agree the increase in encoding time is way overkill compared to the minimal quality increase, but I'm used to long x264 encodes from my old pc(I think the x265 ones on the new pc are about 1.5 times faster than x264 on my old pc) and I have plenty of time between movies I encode to get it done so I'm fine with it.

The exact encoding times were:
Final settings:
FTBD-036_x264_10bit: 0:40:26.34
FTBD-036_x265_hevc_10bit: 3:27:50.67

Without full speed tuning(since I don't have a final crf22 encode):
Test encode comparison:
FTBD-036_x265_grain21_r3d3_hevc_10bit: 0:04:47.18
FTBD-036_x265_grain22_r3d3_hevc_10bit: 0:04:30.40

I haven't properly tagged the full crf22 encode in my timing log so I don't know the time, but I think it's actually near identical to crf21, the variation in the tests were probably due to other factors.

 

[SamKook]

Try disabling sao and using cutree and rect without tune

sao is disabled by the grain tuning and rect is on by default for presets slow and higher so I had those already. cutree is on for all presets, but the tuning is disabling it since it doesn't play nice with the grain stuff.

With only that and my tuning for speed, it looks quite a bit softer so not good:


And if I leave in the psy-rdoq and psy-rd tuning and your stuff to retain a bit more detail it's better but not as good:


Both of those screenshots are slightly bigger than the rip with my settings, but the 1 2 min test(I'm too used to 60fps instead of 30) I use for those comparison are much smaller:
29.31MB for mine
20.09MB for yours
22.32MB for the mix of both

 

[Kevin_san]

what are your settings for deblocking, in case you use dgdecode?
MPEG2Source ("D:\Aki_LPFD-214\Aki_LPFD-214.d2v",cpu=5,moderate_h=55,moderate_v=65,info=2)
it seems that stronger deblocking disturbes the deinterlacer. deringing is helpful for many sources.

I'm currently at compression=18, to prevent the encoder from blurring and eating too much, filesize results im 2.7G because of the noise and shimmer.
normally I go as high as 21, but 19 has been the most frequent value lately.
intermediate result looks quite interesting (added to #77) .
currently testing values for cabac filter and threshold, but this is interpreted by the players if I have understood correctly.