x265 HEVC Encoder

[Kill3rWolf]

Use --ctu 32. Rskip 2 is useful for retaining details, CTU 64 much less (if at all) so.

use rskip 1 and ctu 32

Got confusion. (Boulder) Rskip 2 & (microchip8) rskip 1. Same topic, but with a different value.

[Kill3rWolf]

https://i.ibb.co/s5KJWHf/HEVC-Tier.png (https://ibb.co/B4yKnNp)
Could you tell me perfect vbv-maxrate= & vbv-bufsize= value for Level 4.1 Main tier (Blu-ray encoding)?
Should I set 20,000 for both?
Can I do vbv-maxrate=12000 & vbv-bufsize=20000 without any error?

I saw that an encoder did vbv-maxrate=18000 & vbv-bufsize=24000 for Main 10@L5.1@Main.

[Boulder]

Got confusion. (Boulder) Rskip 2 & (microchip8) rskip 1. Same topic, but with a different value.

--rskip 2 is better for detail retention. --rskip 1 is the same as the old --rskip. I recommend using --ctu 32 regardless of the rskip setting.

[_kermit]

--rskip 2 is better for detail retention. --rskip 1 is the same as the old --rskip. I recommend using --ctu 32 regardless of the rskip setting.

with --rskip 2 I had tearing, not using that anymore.

[rwill]

with --rskip 2 I had tearing, not using that anymore.

Tearing ? You mean what you reported here ?:
https://forum.doom9.org/showthread.php?p=1960919#post1960919

You had quite a lot of parameters. By that logic you don't set any of these now ?

[Kill3rWolf]

Guys, need help regarding HEVC Level, Tier vbv-maxrate= & vbv-bufsize= value.

[Gravitator]

Massive tearing, at least I think that's what it's called: https://ibb.co/fSYXTQ0

it's a specific scene of Mission Impossible - Rogue Nation starting at 1.09.56 (original: https://ibb.co/9GhV3wx)

any ideas how to prevent that?
are my params the reason (hence the question above)?

Can you provide a sample (30 sec)?

[excellentswordfight]

[url=https://ibb.co/B4yKnNp]
Could you tell me perfect vbv-maxrate= & vbv-bufsize= value for Level 4.1 Main tier (Blu-ray encoding)?

The "perfect" values depends on your target device & playback variables.

Should I set 20,000 for both?

You could, that is also what the encoder sets if you specify that level.

Can I do vbv-maxrate=12000 & vbv-bufsize=20000 without any error?

As long as its not above the max value of the level you want to use, yes.

I saw that an encoder did vbv-maxrate=18000 & vbv-bufsize=24000 for Main 10@L5.1@Main.

Ok?

[_kermit]

Tearing ? You mean what you reported here ?:
https://forum.doom9.org/showthread.php?p=1960919#post1960919

You had quite a lot of parameters. By that logic you don't set any of these now ?

yes, that screen (btw how is that called properly?)

and I kept everything just skipped --rskip 2 (which I'm still wondering if that is a good thing, but those I collected over time. I'd prefer to keep it more simple or better ones if possible)

that above went away, I try now with --rskip 1 to get more FPS.

[_kermit]

Can you provide a sample (30 sec)?

the first screenshot shows it (if still online). That specific scene is all like that, while there is like "doublevision" of her (screen two) in the original.

[rwill]

yes, that screen (btw how is that called properly?)

and I kept everything just skipped --rskip 2 (which I'm still wondering if that is a good thing, but those I collected over time. I'd prefer to keep it more simple or better ones if possible)

that above went away, I try now with --rskip 1 to get more FPS.

If the screen is covered with tiny blocks or garbage that do not fit the bitrate like in this case I would call it encoding or decoding error or encoder/decoder mismatch. Its an error that is caused by the encoder trying to do one thing and writing it out but the decoder is doing another thing upon reading it in, leading to complete disaster. Once broken by such an error the encoding/decoding process most likely does not recover until the next random access point. In simpler terms it is a miscommunication of picture contents between encoder and decoder.

This can be caused by some bug or out of spec behavior in the encoder or decoder where the standard ( here h.265 ) is not followed correctly. If you used hardware decoding to produce that output the most possible cause lies in the encoder because hardware decoders are tested very thoroughly before being cast in silicon.

These type of problems can be debugged by cutting the source down to some small sample which triggers the effect every time it is decoded with one specific or all decoders. So to fix it one needs the small input sample, the encoder in a specific version in source form, the encoder configuration and the decoder in source form in a specific version. Oh and the H.265 standard. Then you can see at which point the encoder and decoder start to differ in the encoding/decoding process. Large samples where things start to happen one hour in are useless because their are very cumbersome to debug.

Could be that the rskip 2 codepath triggers some problem but it might also be that due to all the dependencies a bitstream and encoder / decoder state has a very rare condition somewhere else in the encoder or decoder is triggered by pure chance.

Then again maybe just some frame is too large or the decoder application is feeding DXVA2 wrong at your 160MBit rate.

[benwaggoner]

with --rskip 2 I had tearing, not using that anymore.
Turning down the --rskip-edge-threshold some should fix the tearing while still preserving some of the speed improvements. I find 2-3 works pretty well with the content I've tested with it.

[rwill]

Turning down the --rskip-edge-threshold some should fix the tearing while still preserving some of the speed improvements. I find 2-3 works pretty well with the content I've tested with it.

Have you seen the screenshot he provided ?

[Kill3rWolf]

I have a question, Which one is better, max-luma=255 or max-luma=1023? or depend on the source?

Which one provides bad quality, I mean incorrect colors & too much unacceptable brightness.

[GEfS]

I have a question, Which one is better, max-luma=255 or max-luma=1023? or depend on the source?

Which one provides bad quality, I mean incorrect colors & too much unacceptable brightness.

the value already tells the reason, 255 (0-255, 256 values, 2^8) is 8 bit, 1023 (0-1023, 1024 value, 2^10) is 10bit, it depends on your in and output

[Kill3rWolf]

https://ibb.co/2NRL0P9

@Ben Waggoner, Should I use aq-mode=4 only for 4k HDR content? What about 1080p SDR content? aq-mode=4, Is it still unstable? Can be used for almost all content?

https://iopscience.iop.org/article/10.1088/1742-6596/2078/1/012029/meta

[FranceBB]

I have a question, Which one is better, max-luma=255 or max-luma=1023? or depend on the source?

Which one provides bad quality, I mean incorrect colors & too much unacceptable brightness.

That's full range, though.
for 10bit Limited TV Range I use:

--min-luma 64 --max-luma 940

[Kill3rWolf]

That's full range, though.
for 10bit Limited TV Range I use:

--min-luma 64 --max-luma 940

What's the actual benefit of doing it? I mean behind the reasons.

[excellentswordfight]

What's the actual benefit of doing it? I mean behind the reasons.
It sets what values the encoder excepts for the incomming signal, values above/below are clipped. I.e. if you set this incorrectly you will mess upp the luma values of your encode.

It's very unlikely that you need to specify this manually unless you have good reason for it.

[Kill3rWolf]

It's very unlikely that you need to specify this manually unless you have good reason for it.

Yeah, that's why ain't gonna touch it.

[higher]

Hello Gents!

I discovered that my x265 encodes (1080p, 2160p) lately are not gpu H/W accelerated in mpc-hc and are decoded on the cpu. My older encodes are playing with gpu H/W acceleration. Is there a flag that I have messed with or what could be the culprit? I'm using a gui called hybrid and mkvmerge.

Thanks!

[microchip8]

Hello Gents!

I discovered that my x265 encodes (1080p, 2160p) lately are not gpu H/W accelerated in mpc-hc and are decoded on the cpu. My older encodes are playing with gpu H/W acceleration. Is there a flag that I have messed with or what could be the culprit? I'm using a gui called hybrid and mkvmerge.

Thanks!

without the full command line, it's hard to guess

[Boulder]

Or post a MediaInfo output of both cases so it's to see what the basic difference is.

[higher]

Thanks to both of you for the help. I was using the slow preset and some extra command line options. Upon comparing the encoding settings of a new and an older file via MediaInfo I saw no difference. I reset hybrid and now the encode is H/W accelerated in mpc-hc. Don't know what went wrong. :)

[Kill3rWolf]

Does gamma increase at a certain point bother you while watching a movie/tv-series? Can you identify with your open eyes without any tools while watching? Do you every time check you have achieved correct gamma after encoding a video with any tools/soft?

I'm talking'bout gamma increase due to encoding error, wrong parameters/values. How can I prevent this problem? I mean a specific settings/value/command line.

http://xahlee.info/img/what_is_gamma_correction.html

[MeteorRain]

This is because it cannot get the amount of frames from the piped stream.

It is possible but requires a patch to the y4m input handler code.

y4m [info]: 2560x1064 fps 24000/1001 i420p10 frames 0 - 70330 of 70331

[benwaggoner]

https://ibb.co/2NRL0P9

@Ben Waggoner, Should I use aq-mode=4 only for 4k HDR content? What about 1080p SDR content? aq-mode=4, Is it still unstable? Can be used for almost all content?

https://iopscience.iop.org/article/10.1088/1742-6596/2078/1/012029/meta
Yeah, --aq-mode 4 can be used with all color spaces. The only one that is really color space specific is --aq-mode 3, which is --aq-mode 2 with a bias for lower QPs near black, to address SDR's insufficient code values in low luma.

The right aq mode can depend on content and other parameters, but I generally find --aq-mode 4 to be the best default these days. In particular, it generally handles high grain/noise better than the default of --aq-mode 2.

[benwaggoner]

It sets what values the encoder excepts for the incomming signal, values above/below are clipped. I.e. if you set this incorrectly you will mess upp the luma values of your encode.

It's very unlikely that you need to specify this manually unless you have good reason for it.
And there is a downside to clamping with content that has excursions below nominal black, like analog sources.

Even if black averages out at Y'=64 or =16, noise can result in some pixels having values somewhat lower and others somewhat higher. Clamping to nominal black will leave around half the pixels at nominal black and the others somewhat higher. That results in black areas actually averaging brighter than nominal black, and can leave a "boiling oil" appearance. And the resulting sharp edges are harder to encode, increasing artifacts and/or wasting bits.

I don't know that I've ever set those values in a real encode. Setting a maximum value would be less fraught because SDR has slight code differences be much less visible near white.

If I had to set a minimum value for some reason, I'd want to set it at maybe 75% of nominal black to allow for some random noise without clamping. So maybe 48 for 10-bit and 12 for 8-bit? It would be both context and content dependent.

[benwaggoner]

Hello Gents!

I discovered that my x265 encodes (1080p, 2160p) lately are not gpu H/W accelerated in mpc-hc and are decoded on the cpu. My older encodes are playing with gpu H/W acceleration. Is there a flag that I have messed with or what could be the culprit? I'm using a gui called hybrid and mkvmerge.
Perhaps you're using 10-bit with 8-bit only capable hardware, or exceeding the hardware decoders' maximum Profile @ Level support?

First step is to compare before/after in MediaInfo. I'd guess Profile or Level are higher in the newer encodes.

[benwaggoner]

Does gamma increase at a certain point bother you while watching a movie/tv-series? Can you identify with your open eyes without any tools while watching? Do you every time check you have achieved correct gamma after encoding a video with any tools/soft?

I'm talking'bout gamma increase due to encoding error, wrong parameters/values. How can I prevent this problem? I mean a specific settings/value/command line.
http://xahlee.info/img/what_is_gamma_correction.html
Accidentally changing gamma in encoding isn't that common. A lot more common source of different apparent brightness is a full/limited range mismatch. For example, encoding limited range 16-235 as full range 0-255. That'll yield a file where the darkest pixel is 16 points above actual black, and the brightest 20 below actual white. It also reduces saturation.

Lots of variants of that problem happen all too often, like when a device decodes 16-235 and assumes it is 0-255 RGB. Or when reencoding presuming the wrong source color space.

[higher]

I have been trying to encode the Taxi Driver UHD Blu-Ray. I have some issues and I think it has to do with the heavy grain. There are cyan patches during the intro sequence in the smoke and also throughout the movie. Please see the linked screenshot which is tonemapped to SDR by madVR. The original doesn't have it and frankly I have seen it before with some encodes. This particular encode is around 40Mbit/s and I used the slow preset. I was trying different aq-modes and strength, tune grain but all have this issue. Is there anything else I could experiment with?

Taxi Driver (https://ibb.co/v15SzkL)

[quietvoid]

You could try lowering chroma QP offsets (--cbqpoffs, --crqpoffs. try around -2 to -4), but this is really a x265 weakness with heavy grain.
It has no problem retaining the luma noise but chroma noise is just a mess.

[higher]

Thank you for the suggestion. Unfortunately it made no difference. It's what it is then? :)

[RanmaCanada]

Thank you for the suggestion. Unfortunately it made no difference. It's what it is then? :)

Sadly yes. I've stated it before and I'll state it again, x265 just can't handle grain as well as x264 can. It has gotten better, but it still can't handle it properly. Maybe AV1 or VVC will be able to match x264 in regards to grain handling once they become mature.

[Boulder]

Sadly yes. I've stated it before and I'll state it again, x265 just can't handle grain as well as x264 can. It has gotten better, but it still can't handle it properly. Maybe AV1 or VVC will be able to match x264 in regards to grain handling once they become mature.

As far as I've understood, they will happily suck all the details as well.

To the OP: did you use --hdr10-opt? It will do some internal changes in encoding.

[higher]

Of course I did. Upon further inspection it looks slightly better with --tune-grain but not so much. :)
What are they using for the disc encodes that outperforms x265 in these situations?

[microchip8]

What are they using for the disc encodes that outperforms x265 in these situations?

Ateme or MainConcept or Beamr

[rwill]

Sadly yes. I've stated it before and I'll state it again, x265 just can't handle grain as well as x264 can. It has gotten better, but it still can't handle it properly. Maybe AV1 or VVC will be able to match x264 in regards to grain handling once they become mature.

You are mixing standards with standard implementations.

[rwill]

Ateme or MainConcept or Beamr

Or In-House encoders which are actually tuned for such high rates.

[markiemarcus]

Thank you for the suggestion. Unfortunately it made no difference. It's what it is then? :)

I've also seen this before. In my experience some AQ modes exacerbate the problem and are more prone to it than others. This actually came up on an animated source in a shot not dissimilar to this.

Edit: It's been a while, but IIRC AQ mode 4 worked well on flat gradients with lots of grain. Have you tried this mode or just 1-3?

[RanmaCanada]

You are mixing standards with standard implementations.

The only reason I am is because even their current implementations of grain retention, suck hard. Until the individual encoders properly address it, I think it's fair to lump them together.

[benwaggoner]

--preset grain needs a complete refactor. I recently had some quality issues with grainy HDR stuff that got a big improvement by removing --tune grain. Some things that work better:
using --rd 4 instead of --rd 6
lowering --ipratio and --pbratio some
Increasing --psy and --psyrdoq some
Using --rskip 2 instead of --rskip 1, and with a lower threshold than the default
A lot of --nr-inter with --nr-intra maybe 25% of that

[excellentswordfight]

Of course I did. Upon further inspection it looks slightly better with --tune-grain but not so much. :)
What are they using for the disc encodes that outperforms x265 in these situations?
Could you upload a 1min sample from the source file and your re-encode?

[jauh]

--preset grain needs a complete refactor. I recently had some quality issues with grainy HDR stuff that got a big improvement by removing --tune grain. Some things that work better:
using --rd 4 instead of --rd 6
lowering --ipratio and --pbratio some
Increasing --psy and --psyrdoq some
Using --rskip 2 instead of --rskip 1, and with a lower threshold than the default
A lot of --nr-inter with --nr-intra maybe 25% of that

After a fair bit of experimenting, I've got this to replicate most of the film grain (where the grain is akin to salt-and-pepper noise) on the default preset (so no psyrdoq) for 1080p with reasonable bitrates (6~10Mbps):-


--crf 20 \
--pmode --pme \
--ref 6 --bframes 16 --weightb --deblock -4:-1 --lookahead-slices 1 \
--min-keyint 24 --keyint 240 --b-intra \
--analyze-src-pics --me star --no-early-skip --rskip 0 --fades \
--no-limit-modes --rd 6 --subme 5 --rc-lookahead 240 \
--merange 58 --max-merge 5 --qpstep 1 \
--rd-refine \
--tu-intra-depth 4 --tu-inter-depth 4 \
--psy-rd 4 \
--aq-mode 2 \
--no-cutree \
--ipratio 1.1 \
--no-sao \
--limit-refs 0 \
--qg-size 64


but even with that I'm struggling with "giant grain" like the pilot of TBBT where the rates shoot up past 20Mbps.

I found that lowering --pbratio was just wasting too much bandwidth. The main things that "turned the tide" were --no-sao and --no-cutree (cutree created artefacts where non-patterned objects would have a "noise halo" when they moved against a patterned object (like a door with woodgrain) when film grain was present on the patterned object). I also initially had --psy-rd at 4.5 but dropped it down to 4 as the extra .5 didn't seem to make that much difference.

[benwaggoner]

@jauh
Did you try my suggestions? If so, with what results?

Also?
What preset are you using?
Are you actually getting a speed increase with --pme? If so, what resolution and how many cores?
How did you come up with --deblock -4:-1?
--refs 6 and especially --bframes 16 seem unlikely to help with grain much. Did you compare with lower values?
Why --analyze-src-pics? What impact did it give? That's normally a performance optimization, not a quality one.
Why --me-range 58 instead of 57?
--qg size 64 is interesting, but makes some sense as it would reduce fine QP variation.
Did you see any benefit from --fades?

Also:
--rd-refine shouldn't do anything in a 1-pass encode
Was even --pbratio 1.3 counterproductive?

[jauh]

@benwaggoner:-

I made modifications to my usual config off your suggestions using the "scientific poke" method, but not tried any one specific in isolation. I'm running on the default preset, i. e. no explicit --preset option.

It's 1080p material, and on a 16C/32T CPU pme makes a huge difference in churning frames (sub-1fps to over 2fps).

Deblock was a trial and error based on a scene where over-blurring/blocking was evident, so I just fiddled till the balance was right.

--ref 6 was a hang-over from non-grain/noise material, and you're right, if the material is sufficiently noisy you're not going to get many back refs, but in that case it should make no difference what the number is anyway

--bframes 16 is purely an economics decision based on the cost of signalling of B frames (for most part, I get 3--5 consecutive B frames, but even with the fractional percentage of double-digit consecutive B frames you end up saving some space)

I'm all up for squeezing even fractional performance, so --analyse-src-pics is in ;)

--me-range is a 58 because the -1 is a penalty for hex, since I'm using star there's no point penalising self (although I'm experimenting with hme, see later on).

--rd-refine is doing something even in 1-pass, not certain whether what it's doing is necessarily good or bad though:-

with --rd-refine

x265 [info]: frame I: 8, Avg QP:18.69 kb/s: 35639.33
x265 [info]: frame P: 88, Avg QP:20.08 kb/s: 19036.22
x265 [info]: frame B: 404, Avg QP:21.80 kb/s: 5604.48
x265 [info]: Weighted P-Frames: Y:1.1% UV:1.1%
x265 [info]: Weighted B-Frames: Y:3.0% UV:1.0%
x265 [info]: consecutive B-frames: 8.3% 7.3% 2.1% 26.0% 15.6% 16.7% 8.3% 11.5% 1.0% 0.0% 0.0% 0.0% 0.0% 1.0% 0.0% 0.0% 2.1%

encoded 500 frames in 202.93s (2.46 fps), 8449.02 kb/s, Avg QP:21.45


without --rd-refine

x265 [info]: frame I: 8, Avg QP:18.67 kb/s: 35633.43
x265 [info]: frame P: 88, Avg QP:20.38 kb/s: 19123.22
x265 [info]: frame B: 404, Avg QP:21.88 kb/s: 5997.30
x265 [info]: Weighted P-Frames: Y:1.1% UV:1.1%
x265 [info]: Weighted B-Frames: Y:3.0% UV:1.0%
x265 [info]: consecutive B-frames: 8.3% 7.3% 2.1% 26.0% 15.6% 16.7% 8.3% 11.5% 1.0% 0.0% 0.0% 0.0% 0.0% 1.0% 0.0% 0.0% 2.1%

encoded 500 frames in 183.40s (2.73 fps), 8781.64 kb/s, Avg QP:21.57


I had a scene where an opening door cast a progressing shadow on a wall, tried increasing crf till x265 produced blocking artefacts, that happened at crf 22, so I dropped pbratio to even 1.0 and that made no difference at crf 22, at crf 21, pbratio of 1.4 was adequate, so I didn't really bother fiddling with that. x265 has a weird rate control mechanism:- I noticed that when I dropped ipratio, the average bitrate of the completed encode didn't change much (<<10%), the thing that did change was the average cost of each type of frame, go figure!


The "see later on" part:-
I've noticed on one of the encodes that grain/noise over a patterned object (again, think door with woodgrain) resulted in a paintbrush smear effect when the camera strictly tilted up during a scene, hme seems to have mitigated that somewhat, but I'm still working on eliminating that completely (not present in the original encode) without throwing a ton of bandwidth at it.


edit:- the culprit of the paintbrush smear effect seem to have been --limit-tu 0, and the effect is gone even at --limit-tu 1, the flip side of increasing --limit-tu is a bump in the average signalling cost

limit-tu 0, paintbrush smear:-

x265 [info]: frame I: 7, Avg QP:18.43 kb/s: 34261.16
x265 [info]: frame P: 95, Avg QP:19.89 kb/s: 21423.34
x265 [info]: frame B: 398, Avg QP:21.42 kb/s: 6820.33
x265 [info]: Weighted P-Frames: Y:2.1% UV:2.1%
x265 [info]: Weighted B-Frames: Y:3.0% UV:1.3%
x265 [info]: consecutive B-frames: 7.8% 4.9% 2.9% 37.3% 12.7% 18.6% 9.8% 2.9% 0.0% 0.0% 0.0% 0.0% 0.0% 1.0% 0.0% 0.0% 2.0%

encoded 500 frames in 319.25s (1.57 fps), 9979.07 kb/s, Avg QP:21.09


limit-tu 1, no paintbrush smear:-

x265 [info]: frame I: 7, Avg QP:18.43 kb/s: 34261.16
x265 [info]: frame P: 95, Avg QP:19.84 kb/s: 22190.47
x265 [info]: frame B: 398, Avg QP:21.27 kb/s: 7802.09
x265 [info]: Weighted P-Frames: Y:2.1% UV:2.1%
x265 [info]: Weighted B-Frames: Y:3.0% UV:1.3%
x265 [info]: consecutive B-frames: 7.8% 4.9% 2.9% 37.3% 12.7% 18.6% 9.8% 2.9% 0.0% 0.0% 0.0% 0.0% 0.0% 1.0% 0.0% 0.0% 2.0%

encoded 500 frames in 317.05s (1.58 fps), 10906.31 kb/s, Avg QP:20.96

[higher]

--preset grain needs a complete refactor. I recently had some quality issues with grainy HDR stuff that got a big improvement by removing --tune grain. Some things that work better:
using --rd 4 instead of --rd 6
lowering --ipratio and --pbratio some
Increasing --psy and --psyrdoq some
Using --rskip 2 instead of --rskip 1, and with a lower threshold than the default
A lot of --nr-inter with --nr-intra maybe 25% of that

A lof of suggestions to try. Need to decrypt the disc again to try these as I already deleted the original.

By the way some of the Amazon Video 4K HDR encodes also have these cyan patches but even on light grain. Recently I have noticed it on Reacher but I remember the 4K HDR version of Wrath of Man on Amazon also have these discolorations unlike the UHD disc version.
Are you using x265 for 4K HDR on Amazon Video, Ben?

Reacher (https://ibb.co/pjy68Lc) - screenshot tonemapped to SDR by MadVR; I have a Prime sub but I had to download it from elsewhere to be able to make screens. :)

Check the wall under the picture and the sheets on the table. Looks quite ugly.

Prime Video's 4K bitrates of 14-15 Mbit/sec should also be higher. It doesn't really cut it with grainy, high motion materials.

Look at this mess. (https://ibb.co/MRNnK8s) There's hardly any motion here yet it looks terrible.

AppleTV+ is around 23-24 Mbit/sec and it definitely shows.

[Boulder]

The "see later on" part:-
I've noticed on one of the encodes that grain/noise over a patterned object (again, think door with woodgrain) resulted in a paintbrush smear effect when the camera strictly tilted up during a scene, hme seems to have mitigated that somewhat, but I'm still working on eliminating that completely (not present in the original encode) without throwing a ton of bandwidth at it.


edit:- the culprit of the paintbrush smear effect seem to have been --limit-tu 0, and the effect is gone even at --limit-tu 1, the flip side of increasing --limit-tu is a bump in the average signalling cost


The combination of rskip mode 2, CTU 64 and --limit-tu 0 is broken, and I'd expect rskip mode 0 to be broken as well since it means just disabling all recursion skipping instead of limiting it (mode 2).

https://forum.doom9.org/showthread.php?p=1919347#post1919347

[Kuler087]

Reacher (https://ibb.co/pjy68Lc) - screenshot tonemapped to SDR by MadVR :)

Check the wall under the picture and the sheets on the table. Looks quite ugly.


yep, amazon HEVC encoding is horrible. Much worse than Netflix and Disney+ while using roughly the same bitrate

[jauh]

The combination of rskip mode 2, CTU 64 and --limit-tu 0 is broken, and I'd expect rskip mode 0 to be broken as well since it means just disabling all recursion skipping instead of limiting it (mode 2).

https://forum.doom9.org/showthread.php?p=1919347#post1919347

I've tested your hypothesis with --rskip 1 and --limit-tu 0, and while the smear effect is considerably milder (if I hadn't known to look for it, chances are, I'd not have spotted it) it's still there, so it's likely that there's more than just that combination of switches.