x265 Sharpness and Detail (Best Settings?)

[benwaggoner]

Originally Posted by tormento

What is the difference between tskip and tskip-fast? Why they can be used together? What will happen?

--tskip-fast doesn't do anything if --tskip isn't on. If --tskip is on, it will do a slower, more thorough job without --tskip-fast than if it is on. For most content, --tskip is only occassionally helpful, and --tskip-fast catches most of those cases. --tskip by itself has a pretty big perf hit, So I recommend trying it with --tskip-fast first, and seeing if there is any benefit. If there is benefit, try without --tskip fast and see if there is additional benefit worth the slower encoding speed.

[benwaggoner]

In retrospect, it should have been implemented as --tskip 0, 1, or 2, following the other speed/quality ordinal parameters like --me, --subme, --limit-refs, etc.

[jpsdr]

I've made a very quick test on a 10 frames video, speed difference between with and without tskip is 0,52fps to 0,49fps, i can live with that...

[benwaggoner]

Originally Posted by jpsdr

I've made a very quick test on a 10 frames video, speed difference between with and without tskip is 0,52fps to 0,49fps, i can live with that...

I suspect the gap will be larger with a more representative number of frames. You need to encode a decent multiple of --keyint to get accurate performance numbers. 10 frames is less than default --rc-lookahead, and fps is typically way higher for the --rc-lookahead duration.

--rc-lookahead is really a secret weapon for improving quality and reducing quality fluctuations with single-pass encoding.

[jpsdr]

Seeing the speed of a big real encode i've started, I think my true drop is 0,50 average to 0,42 average. It's allmost 20%... I'll check with --tskip-fast... If it catches allmost all the cases for a speed drop less significant, it will be enough for me. rc-lookahead is set to 48.

[HD MOVIE SOURCE]

Yeah, tskip is too impactful on performance with my current step, not the end of the world for me, I'm pretty happy with my current detail settings. I would use rect, amp, hme and tskip if I could, But a full movie is 2 days with my settings, and 20+ days with just adding these 4 settings, so that shows you how much impact they have, and how unoptimized my pc is for encoding, LOL.

Because SolLevante is only around 4 thousand frames, I encoded that using the highest settings possible, placebo and hme / tskip and the quality is shockingly good. Took me 2 days, but I wanted to see it and it doesn't disappoint.

Unless there's anymore settings that Ben is keeping secret from us, I think its about as good as it gets. haha...

[benwaggoner]

Wow, those four commands should NOT cause encoding time to go up 10x! I haven't seen --hme really prove its value yet. Have you?

You can get --amp and --rect with much less of a hit using --limit-refs 2 or 3
And of course, add --tskip-fast with tskip

[jpsdr]

@benwaggoner
What do you know (brief/quick) of the new commited option ?

[benwaggoner]

Originally Posted by jpsdr

@benwaggoner
What do you know (brief/quick) of the new commited option ?

A MCTF filter essentially removes psychovisually irrelevant detail, making the video easier to encode. So better quality at a fixed bitrate, lower bitrate for a fixed quality. It can be quite helpful for moderate-low bitrates.

I've not tried this new implementation yet myself.

[jpsdr]

@benwagonner
Sorry to bother you again...
First, thank for explanation, i read the code of the commit, and from the few i understood, it adjusts, for each frame, according the content, the aq-mode. It seems indeed interesting.
Also, if i understood properly, you just need to put --sbrc, no aq-mode is needed anymore.

--hevc-aq and aq-mode are exclusive. Do you happend to know (by any chance), if there is one "better" than the other ? Or is it just 2 differents ways, but with no one realy better than anoter ?

Don't tested yet --hevc-aq with sbrc, but from the few i understood, they should be also exclusive but see nothing about it in the commited code...

[benwaggoner]

Originally Posted by jpsdr

@benwagonner
Sorry to bother you again...
First, thank for explanation, i read the code of the commit, and from the few i understood, it adjusts, for each frame, according the content, the aq-mode. It seems indeed interesting.
Also, if i understood properly, you just need to put --sbrc, no aq-mode is needed anymore.

That would be welcome! Different modes are appropriate for different kinds of content. And appropriate --aq-strength varies a lot too.

--hevc-aq and aq-mode are exclusive. Do you happend to know (by any chance), if there is one "better" than the other ? Or is it just 2 differents ways, but with no one realy better than anoter ?

IIRC --aq-mode 4 is the final implementation of --hevc-aq.

[jpsdr]

Originally Posted by benwaggoner

IIRC --aq-mode 4 is the final implementation of --hevc-aq.

Ah... Ok...
The, the choice would be between sbrc or aq-mode 5, which are both adaptative AQ modes.

[benwaggoner]

Originally Posted by jpsdr

Ah... Ok...
The, the choice would be between sbrc or aq-mode 5, which are both adaptative AQ modes.

...assuming there is a build which has both --aq-mode 5 and sbrc. And that they mean the same things. That's the tricky thing with forks. I hope we can reunify everything useful back into mainline.

[jpsdr]

Now there is...

[benwaggoner]

Originally Posted by jpsdr

Now there is...

You mean this?
https://github.com/jpsdr/x265

[jpsdr]

Yes it is.

[tormento]

Originally Posted by benwaggoner

...assuming there is a build which has both --aq-mode 5 and sbrc.

You tried to play with 5? I am curious to read your findings about modes above 3.

[benwaggoner]

Originally Posted by tormento

You tried to play with 5? I am curious to read your findings about modes above 3.

I've found --aq-mode 4 to be a good default for SDR content at this point, at least in the context of all the other tuning I do, and with mezzaine quality sources.

--aq-mode 2 does better for hdr still, at least in my target scenarios.

[tormento]

Originally Posted by benwaggoner

I've found --aq-mode 4 to be a good default for SDR content at this point

What about 5?

[benwaggoner]

Originally Posted by tormento

What about 5?

That's only in custom forks that I've not played with.