x265 HEVC Encoder

[Zebulon84]

Originally Posted by pingfr

x265 really needs to massively improve in details retention in that specific area if it wants to be "taken seriously" compared to other HEVC encoders.
The loss of details is so ugly, it makes XviD (aka a 15 years old obsolete codec) look better in those regards.

So which other HEVC encoders gives much better detail retention at 1100 kb/s for 1080p ?

[elahn]

Originally Posted by nevcairiel

its certainly something we as the community could easily create, a set of settings that generally keep more quality, but not focused on grain directly.

I would love that! I struggle to understand many of the parameters and I feel like it'll be a long time over many sources before I do, if ever.

[Majorlag]

elahn,
I would look over at http://x265.readthedocs.io/en/default/cli.html and read up on what each option does. This is where I went back to, through many iterations of encodes. I found that there is nothing like trial and error to see what options are worth enabling and others disabling.

The defaults are generally set for a reason, to give an all around acceptable quality for the time it takes to encode at the users desired bitrate. Use a short 24 minute episode to try different settings. Too short of a clip will not show some fine tuning. and long clips will be forever to decide if things like that --preset plecebo was worth it.

Don't get caught up in the chasing options forever and enabling or changing everything, presets are there for a reason, then apply small changes for your needs.

~Majorlag

[LigH]

Originally Posted by Zebulon84

So which other HEVC encoders gives much better detail retention at 1100 kb/s for 1080p ?

a) That would be off-topic here.

b) They all are HEVC encoders, so they all behave in a similar way, and none does miracles. Bitrate is usually spared by decisions which details can be reduced with little annoyance. Such decisions can be more or less appropriate, depending on both the video material and the person looking at it.

[benwaggoner]

Originally Posted by Boulder

Quality is in the eye of the beholder --tune grain is the only one biased toward keeping detail - and detail in this context is "real" detail, grain, noise etc. Some people prefer a clean image for which --tune grain is probably not a perfect choice.

Also, --tune grain is very often suboptimal for quality @ bitrate. So if getting as good subjective quality as is possible at a low bitrate is the goal, --tune grain is only useful with really grainy content, mainly at higher resolutions where the actual spatial frequencies are mainly noise.

[pingfr]

Originally Posted by benwaggoner

Also, --tune grain is very often suboptimal for quality @ bitrate. So if getting as good subjective quality as is possible at a low bitrate is the goal, --tune grain is only useful with really grainy content, mainly at higher resolutions where the actual spatial frequencies are mainly noise.

Not to throw oil on the fire but... finally someone who has a clue and common sense!

--tune grain is for grainy content as the name implies... duh!

--tune grain is not, never was and never will be a "cookie cutter all-around" parameter to always consider when doing encodes. It is not the "always 100% right" solution as others have wrongly implied in the past 3 pages of this thread.

[Boulder]

For what it's worth, the encoder cannot tell grain from actual detail or noise. What we --tune grain users have been saying is that the tuning tends to bias towards keeping things as they are in the source; be it grain, detail or noise. It does this at a cost of a higher bitrate so you most likely will not see the advertised 50% bitrate savings compared to H.264.

As always, everything depends on what you personally seek - you must test things yourself and then use whatever looks best to your eyes. We are only spoon-feeding you options to test.

EDIT: Earlier I posted some sample screenshots here: https://forum.doom9.org/showthread.p...22#post1734222 when I compared x264 and "non-tune-grain" settings of x265 more. I have made short tests after that with more recent builds of x265 every now and then, but the problem of vanishing details is still there unless I use --tune grain.

[pingfr]

Originally Posted by Boulder

It does this at a cost of a higher bitrate so you most likely will not see the advertised 50% bitrate savings compared to H.264.

And therefore should be avoided at all costs as it nullifies the whole point of using x265 over x264 to begin with. /thread

[Boulder]

As I mentioned earlier, my encodes with x265 have generally been 10-30% smaller than the ones with x264 with at least similar visual (subjective) quality.

[WhatZit]

Originally Posted by pingfr

--tune grain is for grainy content as the name implies... duh!

Do I have a different interpretation of this section of the manual than everyone else?

"Tune grain also biases towards decisions that retain more high frequency components."

That's a quality algorithm, right there.

EDIT: Besides, there was NO GRAIN in that Yacht Ride comparison I posted, was there? The non-grain encode was 6.27mb, the grain encode was 10.7mb. Given the massive quality superiority of the grain encode, I consider the expanded bitrate to be well worth it.

[LoRd_MuldeR]

Originally Posted by WhatZit

"Tune grain also biases towards decisions that retain more high frequency components."

That's a quality algorithm, right there.

You need to keep in mind that you have a limited bit budget. And, therefore, any bits you spent for one thing will be missing for something else.

Consequently, the more bits you spend on retaining "more high frequency components", the less bits will be available for the lower frequency components, of course. It's all a trade-off!

At high enough target bitrate that may be okay, but at medium to lower bitrates it can definitely cause problems.

Surely, you can just crank up the bitrate when using "tune grain" - which in CRF mode happens kind of "automatically" - but then again you end up with files of different size (i.e. different average bitrate).

If the file with "tune grain" is allowed to use more bits than the file with "default" settings (without "tune grain"), then any quality comparison of those files will inherently be biased/unfair.

[WhatZit]

Originally Posted by Boulder

It does this at a cost of a higher bitrate so you most likely will not see the advertised 50% bitrate savings compared to H.264.

Originally Posted by pingfr

And therefore should be avoided at all costs as it nullifies the whole point of using x265 over x264 to begin with. /thread

Wait a minute... wasn't it YOU who said THIS:

Originally Posted by pingfr

I'm trying to optimize for top-notch quality at a 10%~15% size/compression efficiency over x264, bitrate isn't an issue and never will be.

Everything I've said so far will allow you to do exactly, precisely THAT!

By now, all I think you want to do is to troll x265, i.e.: complaining about quality while encoding in 8-bits, complaining about quality while encoding at low-bitrates, and/or complaining about size or speed when detail preservation techniques are used.

[aymanalz]

Originally Posted by WhatZit

Wait a minute... wasn't it YOU who said THIS:



Everything I've said so far will allow you to do exactly, precisely THAT!

By now, all I think you want to do is to troll x265, i.e.: complaining about quality while encoding in 8-bits, complaining about quality while encoding at low-bitrates, and/or complaining about size or speed when detail preservation techniques are used.

You don't want to be throwing accusations of trolling etc, when you are solely responsible for the confusion and misinformation over the last two pages. It was your suggestion that "tune grain" should be renamed to "tune quality", with the implication that it is a universal silver bullet for quality. I specifically had to ask everybody else's opinion becaue of your statement, and clearly, the consensus is that "tune grain" is best used for grainy or other noisy sources.

The point of the codec is to get maximum quality at lower bitrates than previous gen codecs. For maximum quality per bitrate, tune grain is suboptimal for non grainy or non noisy sources. As the name implies, it is meant to preserve detail (grain, noise) in grainy sources.

[aymanalz]

Originally Posted by WhatZit

Do I have a different interpretation of this section of the manual than everyone else?

To begin with, you have a different interpretation of the name itself than everybody else. "Tune grain" means precisely that - a preset to retain grain in grainy sources. That is why the developers named it so, instead of as "tune quality", as you suggested.

Originally Posted by WhatZit

Do I have a different interpretation of this section of the manual than everyone else?

"Tune grain also biases towards decisions that retain more high frequency components."

That's a quality algorithm, right there.

Nope. High frequency = grain. That's a grain algorithm. Or more generally, to spend more bits on high frequency components alone. Which works well to retain grain, but not other kinds of detail.

Originally Posted by WhatZit

EDIT: Besides, there was NO GRAIN in that Yacht Ride comparison I posted, was there? The non-grain encode was 6.27mb, the grain encode was 10.7mb. Given the massive quality superiority of the grain encode, I consider the expanded bitrate to be well worth it.

A 10.7 mb file has higher quality than a 6.27 mb file. Surprised? You would see that same quality improvement by feeding more bits to the encode, whether by adjusting CRF or bitrate for a multi pass encode.

If you want to compare quality, do so at the same bitrate/filesize.

[LigH]

Originally Posted by aymanalz

Nope. High frequency = grain.

Not exclusively. High frequencies are also useful for more or less regular patterns, as well as sharp edges.

That's the main problem of "noise filters": They can't "see" whether an area contains desired structure or undesired noise.

[pingfr]

Originally Posted by LigH

They can't "see" whether an area contains desired structure or undesired noise.

Clearly not an expert on the subject but isn't what chroma and luma analysis per "area" of a given frame are for?

I mean they could be used to help the encoder "see" whether an area is a background with less details where less details/less bitrate can be spent over a foreground area where details/higher grain retention is more crucial because that's the area of the frame our eyes are focused on?

[WhatZit]

Originally Posted by aymanalz

High frequency = grain.

You know what ELSE is high frequency?

Hair, textiles, vegetation, dirt, architecture, fur, water, eyelashes, fences, cobblestones, cliff-faces, bulletholes, control panels, spoked wheels, wood... basically, anything which needs to be represented by hard edges.

Now, what would you call those picture elements? I'd call them detail.

A 10.7 mb file has higher quality than a 6.27 mb file. Surprised? You would see that same quality improvement by feeding more bits to the encode, whether by adjusting CRF or bitrate for a multi pass encode.

In fact, you wouldn't see the same quality improvement with a simple application of more bits, because the default x265 removes detail even at low CRF's. You'd have to manipulate a dozen or more options to even come close to the single --tune grain option, or ABR it.

That was the purpose of the demonstration, in fact that's all I'm going on about: to show how one single option can produce output that is the same quality (subjectively) as 20 individually specified options. Yes, different sizes because different regimes. But I don't starve my encodes of bits, so I never run into any "suboptimal" situations.

I've used --tune grain ubiquitously for 100's of encodes in the last 9 months. It never leaves the command line. A year ago, my x265 options stretched for 3 lines! Some people think that makes themselves an elite special snowflake. To me, it was annoying to maintain.

Now, I only vary the preset & crf as required for light, dark, high-motion, high-detail, grainy, clean or any other type of content you care to name, because I have the experience to know what to use. For me, it DOES work as a quality silver bullet, probably because I never starve my encodes of bits. Quality is number one.

Naturally, if you simply don't like it, don't use it. If quality is also not number one for you, definitely don't use it.

[pingfr]

Originally Posted by WhatZit

Some people think that makes themselves an elite special snowflake.

Uuuuhhhhh... okay?

[Romario]

Can someone, please, tell me how can I retain details in 720p and 1080p encodes, bitrate around 1000 for 720p and about 1650 for 1080p

Gesendet von meinem GT-I9295 mit Tapatalk

[LigH]

Originally Posted by Romario

bitrate around 1000 for 720p and about 1650 for 1080p

Assuming 24 fps as low anchor:

1,000,000 bps : 1280 : 720 : 24 fps ~ 0.045 bppf (bits per pixel and frame)

1,650,000 bps : 1920 : 1080 : 24 fps ~ 0.033 bppf

I hope you encode only talk shows or landscape stills. Any more action, and the "pixel bitrate" may be too small to retain enough quality to be satisfied. It is not a reliable estimation, but you seem to expect miracles (thumb rule for DivX was 0.3 bppf, a decimal magnitude more than your target).