x265 HEVC Encoder

[burfadel]

I wonder whether lookahead could be repurposed to allow more efficient use of large CU size, or only use it when it appears most efficient to do so.

[Anthonytex]

Hello everyone, I know that this question was posted a lot of time so apologize: is it true that it's better to encode a 8bit video to 10bit even if the source it's 8 bit? What's the difference? Does the x265 encoder works better? Thank you

[Selur]

is it true that it's better to encode a 8bit video to 10bit even if the source it's 8 bit?

-> Why does 10-bit save bandwidth (even when content is 8-bit)?

[Boulder]

Originally Posted by Ma

I've made some tests about '--qg-size'. For my eyes '--qg-size 32' is better than '--qg-size 16'. After checking all possible values (8, 16, 32 and 64) the best is 64 (PSNR/SSIM and for my eyes). It is a bit strange, the default value in x265 is 32.

Funny thing is that in the "--tune film" thread, the exact opposite was suggested: http://forum.doom9.org/showthread.php?t=172458

Could you repeat the test with some high-detail film content, please?

[Anthonytex]

Originally Posted by Selur

-> Why does 10-bit save bandwidth (even when content is 8-bit)?

Thank you I've read that article, I was looking for something x265 specific rather than a general case

[Dope]

I haven't seen x265 to compress more efficiently in 10-bit. x264 - yes. But not x265.

[poisondeathray]

Originally Posted by Dope

I haven't seen x265 to compress more efficiently in 10-bit. x264 - yes. But not x265.

Those are my findings too

[Anthonytex]

Thank you

[Selur]

Still 10bit makes sense to avoid introducing banding artifacts,..

[Asmodian]

10-bit is still more efficient, only it is a very small improvement with x265 compared to x264. x265 uses a higher bit depth in important places internally, even when set to 8 bit; its internal data structures are not all required to use the same bit depth as the output video.

Also, banding is never good so that is also a quality/size efficiency boost.

[sneaker_ger]

The problem is x265 can produce banding even at 10 bit. x264 10bit doesn't have those problems, it's "fire and forget". Hard to beat if you aim for high bitrate/high quality.
https://forum.doom9.org/showthread.p...53#post1762253

[Ma]

The problem with qg-size could be related to 8bit vs. 10bit question.
I've made tests with 10bit output and I prefer qg-size 64 (for 10bit output).
Maybe the change from 64 to 32 for qg-size was for 8bit output?

[IgorC]

Originally Posted by sneaker_ger

The problem is x265 can produce banding even at 10 bit. x264 10bit doesn't have those problems, it's "fire and forget". Hard to beat if you aim for high bitrate/high quality.
https://forum.doom9.org/showthread.p...53#post1762253

Filmgrain preservation is overrated

Filmgrain is just a noise. Pleasant noise, but still noise.
I’d prefer video source without filmgrain than with it. Two reasons for that. First reason, microscopic details aren’t drowned in grain. Second reason, significantly better compressibility. In the end you have better both: visual quality and compressibility. Win-win situation.

Good news that new Netflix series/shows have much less filmgrain or don’t have it at all.
Instead of blaming x265 developers for not preserving grain it’s time to forget about useless filmgrain to begin with

[Sp00kyFox]

Originally Posted by Motenai Yoda

I would suggest a possible tune animation:

aq-mode 3 aq-strength 0.6 aq-motion qg-size 16 rc-lookahead +20 psy-rd 1.2 rdoq-level 2 psy-rdoq 0.3 deblock 1:-1 cbqpoffs -1 crqpoffs -1

can somebody actually provide an encoding example where aq-mode 3 is beneficial? made some tests a while ago and really can't say that it's better or worse than mode 1. both seem better than mode 2 though.

Originally Posted by Anthonytex

Hello everyone, I know that this question was posted a lot of time so apologize: is it true that it's better to encode a 8bit video to 10bit even if the source it's 8 bit? What's the difference? Does the x265 encoder works better? Thank you

10bit-depth prevents banding artifacts better and since HEVC hardware decoders also support it unlike with AVC I don't see a reason not to use it.

Originally Posted by IgorC

Instead of blaming x265 developers for not preserving grain it’s time to forget about useless filmgrain to begin with

it's the classic problem of video filtering to distinguish between grain and details. so a video encoder that fails to keep this picture information also has issues with keeping details. despite that grain can also create details over the temporal axis.

anyways, since the introduction of the new lambda tables (in v2.4) x265 does a great job with keeping grain. for me it has made x264 obsolete.

[IgorC]

Originally Posted by Sp00kyFox

anyways, since the introduction of the new lambda tables (in v2.4) x265 does a great job with keeping grain. for me it has made x264 obsolete.

Great.Thank you for clarifying that as I didn't followed x265 devt last year.

[LigH]

x265 2.6+39-01b685d6fa33

CMake: fix generation of version info from .hg_archival.txt; fix output to pipe on Windows (enable binary mode)

[Barough]

x265 v2.6+42-52782aeb2081 (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[VoodooFX]

Originally Posted by sneaker_ger

The problem is x265 can produce banding even at 10 bit. x264 10bit doesn't have those problems, it's "fire and forget". Hard to beat if you aim for high bitrate/high quality.
https://forum.doom9.org/showthread.p...53#post1762253

Definitely I had same problem with aq-mode=2 (and maybe with 3 too, I don't remember now), using default aq-mode=1 solved exact banding like in those screenshots.

[hajj_3]

x265 v2.7 is out, can't find a changelog though.

[Barough]

https://bitbucket.org/multicoreware/x265/commits/all

Version 2.7
===========

Release date - 21st Feb, 2018.

New features
------------
1. : option: '--gop-lookahead' can be used to extend the gop boundary (set by '--keyint'). The GOP will be extended, if a scene-cut frame is found within this many number of frames.
2. Support for RADL pictures added in x265.
: option: '--radl' can be used to decide number of RADL pictures preceding the IDR picture.

Encoder enhancements
--------------------
1. Moved from YASM to NASM assembler. Supports NASM assembler version 2.13 and greater.
2. Enable analysis save and load in a single run. Introduces two new cli options `--analysis-save <filename>` and `--analysis-load <filename>`.
3. Comply to HDR10+ LLC specification.
4. Reduced x265 build time by more than 50% by re-factoring ipfilter.asm.

Bug fixes
---------
1. Fixed inconsistent output issue in deblock filter and --const-vbv.
2. Fixed Mac OS build warnings.
3. Fixed inconsistency in pass-2 when weightp and cutree are enabled.
4. Fixed deadlock issue due to dropping of BREF frames, while forcing slice types through qp file.