x265 HEVC Encoder

[LigH]

Still no shared samples to compare objectively?

[jd17]

Originally Posted by WhatZit

I recently spent two weeks explaining to everyone how one single option utterly neutralises this default behavior. You must have missed it.

I must have missed that too.
Would you be so kind as to enlighten me?

I am not unhappy with the performance of x265, a combination of 10bit, CRF17, no-sao and preset slow looks transparent to me.

However, I am very interested in the option you are talking about and I would like to do some comparisons myself, so please share!


Edit:
I searched for even older posts from you than I did before and stumbled over this:
https://forum.doom9.org/showthread.p...61#post1800261

Is that what you are talking about? Using --tune grain?

If that is the case, I agree that --tune grain can work wonders, I used to encode with that option too.
However, while I am convinced of the --tune grain results when using --preset medium, I found that --tune grain added to --preset slow (or slower presets than slow) does too much.
This may sound weird, but it looked to me as if it then introduces noise/grain where there is none in the source.
I assume that the high --psy-rdoq (10) might be the root cause for what I consider artificial noise/grain.

[WhatZit]

Originally Posted by jd17

I found that --tune grain added to --preset slow (or slower presets than slow) does too much.
This may sound weird, but it looked to me as if it then introduces noise/grain where there is none in the source.

You're not imagining any of it, JD.

The slower the preset, the more "overboard" the detail retention gets (ridiculously so at veryslow). Also, the new lambda tables seem to have made the phantom grain effect more pronounced.

That's why you always need to think in opposites with --tune grain: go faster with lower bitrates, and let the special algorithms for stable quantization & high-frequency bias do the work of traditional slower presets and higher bitrates.

Originally Posted by LigH

Still no shared samples to compare objectively?

Having to use 3rd party sites to host these dissuades a lot of people, I reckon. Including myself, who's already wasted too much time on frame-grab comparisons that are now auto-deleted.

Now, if doom9 had it's own flick-tool feature...

[jd17]

Originally Posted by WhatZit

You're not imagining any of it, JD.

The slower the preset, the more "overboard" the detail retention gets (ridiculously so at veryslow). Also, the new lambda tables seem to have made the phantom grain effect more pronounced.

That's why you always need to think in opposites with --tune grain: go faster with lower bitrates, and let the special algorithms for stable quantization & high-frequency bias do the work of traditional slower presets and higher bitrates.

That is interesting, I'm glad that you share my assessment.

After my trials, I pretty much concluded that I get very comparable results by either going medium/grain or slow/no-sao, both with CRF17.
While the medium/grain version is quicker to encode, the resulting bitrate is considerably higher.
This is why I use the before mentioned slow/no-sao now.


I have not seen the negative effects of --no-sao Stephen R. Savage refers to. Not even at close inspection during my trials.

Accordingly, I too would like to see a sample demonstrating the phenomenon.

[Barough]

x265 v2.6+14-f09f3b4a2115 (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

x265 2.6+14-f09f3b4a2115

New options:

   --fullhelp                    Show all options and exit
   --gop-lookahead <integer>     Extends gop boundary if a scenecut is found within this from keyint boundary. Default 0

_

I wonder ... how much GOP lookahead would you consider sensible, in relation to min and max keyframe intervals.

[divxmaster]

Originally Posted by burfadel

I don't see how you could be having so many issues with it. Have you eliminated other possibilities like the video decoder? In any case, if you don't like it don't use it! Constructive criticism with examples would help. Upload a small troublesome clip, take a screenshot of frames with issues, and then they could maybe recreate the issue and work on it. B!tch!ng helps no one.

Thanks Burfadel, I was about to post exactly that, but you beat me to it!

And just to confirm, I have calculated (roughly) 10GB/hr is a bit rate of 22.755mbps.... bad output of x265 1080p at 22.755mbps??? I dont think so.

[Weyoun]

Originally Posted by Stephen R. Savage

I could not care less about your "end users." x265 does not deliver good quality for me.

I am so glad x265 was not created for you.

[birdie]

Originally Posted by Stephen R. Savage

Sorry, but if the quality is bad at 10 GB/hr, it can't be better at 1 GB/hr.

This topic was created to discuss x265 development.

If you have issues with the codec, please create a new thread and post your sources and encoding settings, so that we could all decide whether what you're trying to convey is true or not, and if there's something we or you have overlooked.

As mentioned earlier, 10GB/hr translates to 10*1024*1024*1024*8/3600/1024/1024 = 22.755Mb/sec which will be 100% transparent (unless you want a lossless compression) using x264.

[divxmaster]

Originally Posted by birdie

As mentioned earlier, 10GB/hr translates to 10*1024*1024*1024*8/3600/1024/1024 = 22.755Mb/sec which will be 100% transparent (unless you want a lossless compression) using x264.

Haha, I think you meant "100% transparent (unless you want a lossless compression) using x265" ??

[Boulder]

Out of interest, there was earlier some discussion that --qcomp 0.8 would be better than the default 0.6. Has anyone made any recent tests, especially with --tune grain?

[birdie]

Originally Posted by divxmaster

Haha, I think you meant "100% transparent (unless you want a lossless compression) using x265" ??

I did mean x264.

[divxmaster]

Originally Posted by birdie

I did mean x264.

Oh Ok,
Well 22.755Mbps will be transparent in x264 or x265. Thats a higher bitrate than some bluray masters.

Cheers,
Divxmaster

[Barough]

x265 v2.6+15-57eaef9abfd8 (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[Majorlag]

Originally Posted by Boulder

Out of interest, there was earlier some discussion that --qcomp 0.8 would be better than the default 0.6. Has anyone made any recent tests, especially with --tune grain?

I found --qcomp 0.8 to work perfectly for my needs, but I use --rc-grain since I don't want to change my --qpstep to 1. I use the higher qcomp since x264 days. I lean towards less fluctuation in quantizer compression so I change a few of the settings to reflect that, such as"--qpmin 4 --qpmax 44 --qpstep 4 --qcomp 0.8 --rc-lookahead 30 --rc-grain"

[Motenai Yoda]

I found a discrepancy between documentation and source about qg-size, docs sayz [maxCUSize], source 32, maybe it's related to f0b9b9e?
also dc5d584 set it to 32 for "commandlines with medium and all slower presets", but as fast and faster doesn't change it againg, actually it's 32 for all presets

[Barough]

x265 v2.6+17-7a6d244c922b (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[pingfr]

Merry Christmas to all!

[dipje]

This might have been posted, but if I wanted to re-encode some youtube-HDR files to make them compatible with my set, how do I translate the HDR metadata?
ffprobe gives this:

      Content Light Level Metadata, MaxCLL=2000, MaxFALL=300
      Mastering Display Metadata, has_primaries:1 has_luminance:1 r(0.6800,0.3200) g(0.2649,0.6900) b(0.1500 0.0600) wp(0.3127, 0.3290) min_luminance=0.009900,max_luminance=2000.000000

and this:

Stream #0:0(eng): Video: vp9 (Profile 2), yuv420p10le(tv, bt709/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn, 1k tbc (default)

am I correct that x265 needs:

--master-display "G(2649,6900)B(1500,0600)R(6800,3200)WP(3127,3290)L(99,20000000)" --max-cll 2000,300 --range limited --colorprim bt2020 --colormatrix bt709 --transfer smpte2084

Specially the order for --max-cll which is listed as cll,fall in the help text, and the master-display string where I did every ffprobe value * 10000, is that correct?

[Barough]

x265 v2.6+22-ff02513b92c0 (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default