Assistance with StaxRip

[Kevin_san]

I found out the colormatrix values must be scrambled or the makers of the DVDs don't care.
I know I left out the red to luma influence, because I love the bright shining red. It's more like I end up with anime colors.
Following defaults, it ends up yellow-ish which I dislike. Some progressive idol DVDs look as if they were encoded with the 709 family.

After deinterlacing I do
ConvertToRGB32(matrix="PC.709",interlaced=false,chromaresample="lanczos4")
GeneralConvolution(0, C50g5r4) #which refers to a kernel library
ConvertToYV12(matrix="PC.709",interlaced=false,chromaresample="lanczos4")

I know it's not what help files suggest, but looks best here. Also I go from 0-255, not TV range.
Tablet use, not a big screen.

This project came because when a DVD has issues, most x264 uploads look even much poorer, and the reaction is, that some time later the raw ISO gets uploaded. This is the opportunity to try some artifact removal and get better rainbow colors instead of sepia on brownish on greenish.
I have no issue with most blueray rips and youtube music videos, they look great or ok, so it's not my monitor. In fact with my tampering I get closer to a blueray color appeal.

 

[Porni]

del

 

[SamKook]

I'm not a big fan of upscaling during the encoding process, I prefer to let the player handle that stuff since you can infinitely tweak the results that way with a good renderer(madvr).
But that's a different thing for tablets since players are much more limited on them.
And I prefer sharp vs soft so not personally a fan of your settings either.

I'm curious how you end up with 60fps for progressive material though, don't think I've ever seen a 60p DVD before and frame interpolation on progressive content looks like garbage.

I usually work with JAV and all the IV I've worked with are pretty old by now so probably explains why I didn't see any proper progressive DVDs.

 

[Porni]

I'm curious how you end up with 60fps for progressive material though, don't think I've ever seen a 60p DVD before.

Personally, I would recommend this:

FFmpeg Filters Documentation

ffmpeg.org

flexible settings, can get good results, but slowly

 

[SamKook]

Every progressive interpolated video I've seen always looks way off and unnatural in some spots but I don't know what most used for the interpolation.

 

[Porni]

Every progressive interpolated video I've seen always looks way off and unnatural in some spots but I don't know what most used for the interpolation.

It is, and it is unlikely that the situation will change in the coming years
Personally, I use interpolation when I come across video that are less than 24 fps for some reason

 

[Kevin_san]

I'm not a big fan of upscaling during the encoding process, I prefer to let the player handle that stuff since you can infinitely tweak the results that way with a good renderer(madvr).
But that's a different thing for tablets since players are much more limited on them.
And I prefer sharp vs soft so not personally a fan of your settings either.

I'm curious how you end up with 60fps for progressive material though, don't think I've ever seen a 60p DVD before and frame interpolation on progressive content looks like garbage.

I usually work with JAV and all the IV I've worked with are pretty old by now so probably explains why I didn't see any proper progressive DVDs.

It's of course impossible by conservative ways, I just process accordingly. The first pic on the bridge is from a progressive DVD, no deinterlacer, 30fps. This one is definitely clearer than the original (Aika Sawaguchi, sorry for not saving the frame).
Without artifacts, I get less tired from watching, and the experience is a lot more direct, the girl looks hotter and closer to me this way.
The kernels have a deliberate effect for small screens, to look more 3D or less flat. There is no purpose in reproducing the original when it is flawed anyway.

 

[SamKook]

The purpose to reproducing it even if flawed is to keep as much detail as possible and have the flexibility to process it in different way during playback instead of being locked into it looking better on one device but worse on pretty much everything else.

Sometimes it's worth it to denoise/process a source when it's really bad, but for JAV and especially IV, the source is usually good enough except for a few rare cases that I don't feel the need to.

 

[Kevin_san]

In principle yes, but when half the detail turns out bogus artifact, it becomes individual choice. I do it when I like the girl but the video is technically poor. Most videos I did were from 2004 to 2012. Eyes and teeth should be as perfect as possible. When the cam gets closer, things open up nicely, but much less with the originals. There is oversharpening that makes eyes often ugly.
The big japanese characters seem not to lose detail, or do they? Precision eg. chroma positioning should be improved. The small ones on the poster become a lot better when the video is playing.
For example, Ai Shinozaki and Shizuka Nakamura are legend, also Saaya, but half that stuff is blurred in the first place or has massive halo.
Like many others, I watch with VLC or the Windows system player.

BTW is the encoder in AviDemux standard, or does it have issues?

Anyway, thanks again for taking a look.

 

[SamKook]

Hard to say how good the result is without having the original to compare to.

VLC is fine but there are better options on windows, using a directshow player with madvr as the renderer will give you a better result and more features. I like mpchc personally.

AviDemux has multiple encoders, standard stuff as far as I know.

 

[Kevin_san]

In case it's not obvious, the smaller pics are VLC screen shots with the ISO.

I would need presets for about 10 types of videos, does it auto-switch?
Else I am too lazy to adjust anything any time while watching, so I equalize the videos once for all time, so they achieve similar characteristic and I can jump between the vids without getting distracted by totally different sharpness, color space, artifact intensity..

I started upsizing because the encoders seem to blur almost every time, making pixel radius like 1.1 or 1.2 even with low compression.
The last pic comes from compression=21 and has 720 lines. At 640 lines I use often aq=19. Still it eats detail, it does not come from the convolution.
I don't like "video" or "movie" at all, with all their historical properties like the horrible 24fps, I never go to the movie theater.
I only want direct experience that feels like the screen is merely a window.

 

[SamKook]

The writing one does have some chroma bleed compared to the smaller one, especially obvious on the far left letter where the red and orange spots are much bigger.

You can create profiles in madvr to do many different specific processing depending on certain characteristics from the source.

 

[Kevin_san]

Ah yes, thx for discovering. There are two issues: The chroma is downshifted, probably because notoriously the artwork is using different subsampling positions or whatever, and I adjust only on the live material, not on any artwork, else I would have to split and process every section differently. Would make sense only when there is different frame rate, aspect ratio etc.
The other issue is the resizers and type convertors, they may create smear on some videos. To find out exact subsampling position and type, which is a parameter to some functions, independently of what dgindex claims what it should have been, is cumbersome, so I just use a floating point shifter like this:
function CShft(clip In, float X, float Y) {
w = In.Width()
h = In.Height()
Tmp = In.BlackmanResize(w, h, -X, -Y, w-X, h-Y, 5)
In = MergeChroma(In, Tmp)
return In}
At least I end up with symmetric chroma positions, if I look carefully. This happens in the upsampled domain, which decreases the bleed.
Playback with many ISO files fails chroma position.

 

[SamKook]

That's why I like madvr, you can choose many different resizers for chroma, upscaling and downscaling and you can change which is used depending on the content resolution and the power factor just to name a few.

 

[branbran726]

Ah yes, thx for discovering. There are two issues: The chroma is downshifted, probably because notoriously the artwork is using different subsampling positions or whatever, and I adjust only on the live material, not on any artwork, else I would have to split and process every section differently. Would make sense only when there is different frame rate, aspect ratio etc.
The other issue is the resizers and type convertors, they may create smear on some videos. To find out exact subsampling position and type, which is a parameter to some functions, independently of what dgindex claims what it should have been, is cumbersome, so I just use a floating point shifter like this:
function CShft(clip In, float X, float Y) {
w = In.Width()
h = In.Height()
Tmp = In.BlackmanResize(w, h, -X, -Y, w-X, h-Y, 5)
In = MergeChroma(In, Tmp)
return In}
At least I end up with symmetric chroma positions, if I look carefully. This happens in the upsampled domain, which decreases the bleed.
Playback with many ISO files fails chroma position.

Ah, another person getting a Black man to do their resizing. I hope they're getting good pay & benefits.

Anyway, not to interrupt, but what's the quick-and-not-necessarily-dirty way to use StaxRip on a Blu-ray? I'm given to understand that x265 is a better codec for content in higher definition. What should I be worried about vis-a-vis interlacing or other processing pitfalls? And what kind of encoding time should I expect for 8 hours of content?

 

[SamKook]

Staxrip on bluray is basically the same as a dvd when you use makemkv and the processing always depends on each individual sources. Staxrip probably handles the most common stuff on its own.

As for x265, it can compress more than x264 for any content, but it uses blur instead of noise for compression so it's really easy to destroy much of the source details without realizing if you don't compare with the source so you have to be very careful with it and it's probably around 10 times slower than x264 to encode if not more, haven't tested it in a while though and it'll depend on your preset, I always use slowest so the gap is bigger with it.

 

[Kevin_san]

ASUS TUF is my first device ever that can playback x265 at all.
I tried a couple of encodes, file size came down roughly a 50 percent.
Results did not feel exciting, though technically looked correct.
There is a lot of underestimated culture on meta level, ie. how the shapes of the artifacts really work, and what the style of omission does to the content. This comes from classic CRT TV with interlacing. Massive psycho-optics, to achieve such a huge acceptance over decades.
Now it's the streaming portals, that develop such a clandestine culture. Kids just say it looks good or bad, but there is a lot about it, and it is not about tech per se. I dived into that a bit, but i can only do it for myself and my own pleasure. Obviously, I cannot taste wine for others. This is a very particular ability. Korean pop culture came a long way, now they know what looks great for a mass of people, eg. Blackpink videos. They are using some kind of 3D filter as well, so it looks superior on tablets and smart phones. They developed some harmony between the post processing in the studio, and the compression techniques of the platforms. You see it in the "Ice Cream" video, when you compare the American and the Korean segments.

 

[SamKook]

I did a test with FTBD-036 to try some x265 settings since it's a quick one to encode and at slowest(x264 is tweaked a bit), x264 at crf 18 took 36m and is 1.25GB and x265 at crf 20 took 7h42m and is 1.06GB so almost 13 times slower for a 15% reduction in size.

I used 20 for x265 because that's what I've seen some people recommend that they don't notice a difference, but if you compare them in a way where you can switch between 2 screenshots fast(like by using xnviewmp and switch using page up and page down), the x265 one is noticeably blurrier. During playback, it's not as noticeable but I did like the x264 one better even before I did the screenshot comparison.

x264:

x265:

 

[Porni]

@SamKook I don't know about x265, but anime nerds encode in a special way without presets:

Spoiler: Preset for anime with a standard source type - fine noise

--limit-refs 2 --ctu 32 --max-tu-size 16 --hist-scenecut --no-cutree --no-strong-intra-smoothing --open-gop --cbqpoffs -2 --crqpoffs -2 --lookahead-slices 1 --no-early-skip --tskip --rskip 0 --keyint 240 --ref 4 --bframes 8 --b-pyramid --b-adapt 2 --no-sao --no-sao-non-deblock --aq-mode 3 --aq-strength 1 --deblock 1:-1 --tu-intra-depth 2 --refine-intra 4 --dynamic-refine --tu-inter-depth 2 --me 3 --wpp --subme 7 --crf 15 --b-pyramid --weightb --rd 5 --rdoq-level 2 --psy-rdoq 3 --qcomp 0.72 --refine-mv 3 --analyze-src-pics --max-merge 5

Spoiler: The second version of preset1, if it gives bad results or the file size is too large

--hist-scenecut --no-cutree --no-strong-intra-smoothing --open-gop --cbqpoffs -2 --crqpoffs -2 --lookahead-slices 1 --no-early-skip --tskip --rskip 0 --keyint 240 --ref 4 --bframes 8 --b-pyramid --b-adapt 2 --no-sao --no-sao-non-deblock --aq-mode 3 --aq-strength 1 --deblock 1:-1 --tu-intra-depth 2 --refine-intra 4 --dynamic-refine --tu-inter-depth 2 --me 3 --wpp --subme 7 --crf 15 --b-pyramid --weightp --weightb --rd 5 --rdoq-level 2 --psy-rdoq 3 --refine-mv 3 --analyze-src-pics --max-merge 5

Spoiler: Preset for anime with a strong grain (both digital and for sources that are scans of film)

--no-strong-intra-smoothing --open-gop --cbqpoffs -2 --crqpoffs -2 --no-early-skip --rskip 0 --keyint 240 --ref 4 --bframes 8 --b-pyramid --b-adapt 2 --no-sao --no-sao-non-deblock --aq-mode 3 --aq-strength 1 --qcomp 0.72 --deblock 1:-1 --tu-intra-depth 2 --refine-intra 4 --dynamic-refine --tu-inter-depth 2 --me 3 --wpp --subme 7 --crf 16 --b-pyramid --weightb --rd 5 --rdoq-level 2 --psy-rdoq 4 --refine-mv 3 --analyze-src-pics --max-merge 5

Spoiler: Preset for anime with medium sized digital grain, which causes an increase in average bitrate to 16 - 18 megabits when using preset number 1 and a strong loss of detail when lowering crf in the same

--ctu 32 --rc-lookahead 80 --max-tu-size 16 --no-cutree --open-gop --no-strong-intra-smoothing --cbqpoffs -2 --crqpoffs -2 --lookahead-slices 1 --no-early-skip --tskip --rskip 0 --keyint 240 --ref 4 --bframes 9 --b-pyramid --b-adapt 2 --no-sao --no-sao-non-deblock --aq-mode 4 --aq-strength 1 --deblock 1:-1 --tu-intra-depth 1 --refine-intra 4 --dynamic-refine --tu-inter-depth 1 --me 3 --wpp --subme 7 --crf 14.8 --b-pyramid --weightb --rd 5 --rdoq-level 2 --psy-rdoq 3 --refine-mv 3 --analyze-src-pics --qcomp 0.76 --max-merge 5

 

[Kevin_san]

x265 has better handling of motion in bigger areas, which is cpu-intense. the benefit depends on the video having such elements. else it might end up with similar file size.
this time it looks as if we had cranked up the denoiser a bit, which is probably normal behavior for x265 at higher compression.

(my x264 examples, mostly salvage projects, have the denoiser set between 15-19, targeting file size as well.)
eventually, mpeg2 is completely incompatible in its artifacts, and recompression with mpeg4 that must not lose any detail, will end up with similar file size, given big size comes from motion and small detail like grass in the garden. a long but calm video may compress better.