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)? (http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf)

[Boulder]

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]

-> Why does 10-bit save bandwidth (even when content is 8-bit)? (http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf)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]

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. :p

[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.php?p=1762253#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]

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.php?p=1762253#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]

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.

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.

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]

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 (https://www.mediafire.com/file/or25qe6mbnrzcb5/x265_2.6%2B39-01b685d6fa33.7z)

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 (http://www.mediafire.com/file/gignib95e2xax34/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[VoodooFX]

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.php?p=1762253#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.

[Barough]

x265 v2.7+1-2aa737a99f51 (http://www.mediafire.com/file/pqabb8z0pk344jk/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[LigH]

Is there possibly a merge missing with the default branch?! I get only v2.6+49 there. apparently I need to get the stable branch or the tip, because the merge happened before the milestone...

There used to be reasons why I prefer the default branch.

[Midzuki]

Is there possibly a merge missing with the default branch?! I get only v2.6+49 there. apparently I need to get the stable branch or the tip, because the merge happened before the milestone...


hg clone -r 2aa737a99f51 https://bitbucket.org/multicoreware/x265

[Barough]

Is there possibly a merge missing with the default branch?! I get only v2.6+49 there. apparently I need to get the stable branch or the tip, because the merge happened before the milestone...

There used to be reasons why I prefer the default branch.I used MABS as usual and it output v2.7. Haven't made any adjustments/tweaks to it. (My knowledge in that area is close to zero.)

Sent from my SM-G935F via Tapatalk

[LigH]

In this case, the main issue was knowing that the tip was in stable, not in default. Which ever branch or state you select, there is always a possible case where it would miss one or more commits. I may always have to study the current network of branches, commits, and merges, to decide which revision to update to.

MABS may always use tip; this can be wrong when the most current commit belongs to the rarely updated stable branch, and there was no merge with the often updated default branch yet. Therefore, my additional x265 building scripts prefer the default branch, usually, but it takes only one additional parameter to update to a custom target.

[LigH]

New upload: x265 2.7+1-2aa737a99f51 (https://www.mediafire.com/file/of7jx40crg7f7mh/x265_2.7%2B1-2aa737a99f51.7z)

limitTU: Save intra CU's TU depth when analysis save/load is enabled; dHDR10 parsing fixes; ipfilter kernels split into several separate source files; v2.7 milestone

[Ma]

After some tests I notice that I prefer qg-size 64, 10-bit encoding and options close to default. So I renamed old tune 'anime' to 'cartoon' and added new tune 'anime':
--rc-lookahead *= 2;
--psy-rd /= 2;
--qg-size = 64;
if (preset >= slow) --cbqpoffs = --crqpoffs = -1;
if (preset >= slower) {--frame-threads = 1; --subme += 2;}

Win64 binaries (only 10bit+8bit) and patch file anime2.7z (http://msystem.waw.pl/x265/anime2.7z)

For my tune anime please use option
--tune anime
for Motenai Yoda version please use option
--tune cartoon

[excellentswordfight]

Did a round of some tests from a tears of steal encode in 1080p (x264 25Mbps bluray compatable).

x264 crf18 settings (my usual settings for 1080p rips)
--preset slow --profile high --level 4.1 --crf 18 --keyint 240 --min-keyint 24 --rc-lookahead 48 --tune film
x265 crf18 settings
--preset slow --profile main10 --level-idc 41 --crf 18 --keyint 240 --min-keyint 24 --rc-lookahead 48 --no-sao
x264 2pass settings
--preset veryslow --profile high --level 4.1 --bitrate 7000 --keyint 240 --min-keyint 24 --rc-lookahead 48 --tune film
x265 2pass settings
--preset slow --profile main10 --level-idc 41 --bitrate 7000 --keyint 240 --min-keyint 24 --rc-lookahead 48 --no-sao


Both CRF encodes were pretty much visually lossless, but with a 30% bitrate reduction with x265 (10Mbps vs 7Mbps). And x265 retained visable more detail in the more apples to apples 2pass test.

It's official I'm switching to x265 even for 1080p blurays rips now. The days were x265 just wasnt a good option for high quality (detail retention) 1080p encodes are long gone imo. There have been some great improvement by the x265 devs over the last couple of years imo, bravo!

[Ashok Kumar Mishra]

We are working on efficient aq mode which gives better compression efficiency, it may come in next release.

[burfadel]

What about --ssim-Rd and psy together? I haven't heard any more since it was classed as experimental and disabled psy-rd. I found no issues with using them together.

[Ashok Kumar Mishra]

First I would like to make it clear that both --ssim-rd and --psy-rd can't be applied together. There are three different ways to compute the rd cost in analysis for mode decision.
a) psy-rd: Use psycho visual rate distortion strength
b) ssim-rd: Use ssim value
c) Use only distortion So you can use anyone among the above three to compute the rd cost for mode decision. When ssim-rd is enabled, it uses ssim value of the block for rdo cost calculation and makes psy-rd value 0.
psy-rdoq is a different parameter used for rdoq analysis. It is enabled when you are using --rdoq-level 1. So it can be used along with psy-rd or ssim-rd parameter, since both are two different things used for different purpose.

Hope the above explanation will clarify the conflict between these parameters.

[Heaud]

After some tests I notice that I prefer qg-size 64, 10-bit encoding and options close to default. So I renamed old tune 'anime' to 'cartoon' and added new tune 'anime':
--rc-lookahead *= 2;
--psy-rd /= 2;
--qg-size = 64;
if (preset >= slow) --cbqpoffs = --crqpoffs = -1;
if (preset >= slower) {--frame-threads = 1; --subme += 2;}


I agree with the preset adjustments to rc-lookahead and psy-rd, but I have not tested the other options before. Is setting qg-size to 64 a benefit to compression, quality, or both? Same can be asked on setting frame-threads and boosting the subme value.

Have you tried out --tskip with --tskip-fast enabled? Another user by the name of benwaggoner had suggested these two settings in another thread after noticing positive results.

[Boulder]

Qg-size 64 at least helps in compression based on my experiences.

[sneaker_ger]

"Quality" and "compression" are usually 2 sides of the same coin. You get better quality for same file size, smaller file size for same quality or a bit of both. Only depends on how you set bitrate/crf.

[Ma]

Is setting qg-size to 64 a benefit to compression, quality, or both?

I've made tests with fixed bitrate -- encoding big_buck_bunny_1080p24.y4m with '--tune anime' and without (old tune anime that now I renamed to cartoon). PSNR and SSIM was better with tune anime but for me the quality was wrong. At the beginning in big_buck_bunny_1080p24.y4m there are two birds in top right corner (they flying very far from 'camera'). With qg-size 16 and low bitrate they are fading/disappear too soon and they are not consistent in time/position. With default qg-size 32 the birds looks better but with qg-szie 64 even better. PSNR and SSIM are better with qg-size 64.

You can try encode
x265 -p slow --bitrate 500 --psnr --ssim big_buck_bunny_1080p24.y4m bb1.hevc --tune cartoon
vs.
x265 -p slow --bitrate 500 --psnr --ssim big_buck_bunny_1080p24.y4m bb2.hevc --tune cartoon --qg-size 64
vs.
x265 -p slow --bitrate 500 --psnr --ssim big_buck_bunny_1080p24.y4m bb3.hevc --tune anime

and observe smoothness of flying the birds (not one frame but the move).

[LigH]

Well, BBB is not exactly classical Cartoon/Anime ... unfortunately, I still don't know any original cartoon movie in high resolution. The closest are still computer graphic supported cartoons.

[Ma]

Yes, good samples for trying options for anime are welcome.
I'm testing on:
big_buck_bunny_1080p24.y4m
elephants_dream_1080p24.y4m
lighthouse_lossless.mp4 (not pure anime)
tearsofsteel-4k.y4m (also not pure anime, downsized to 2K)
sintel (4K png version, downsized to 2K)
original.mkv (301762111 bytes anime sample I don't remember where I found it)

I decided to encode all samples at bitrate 1500 with my tune anime (preset veryslow, 10-bit) and watch for blocking/annoying imperfections. Unfortunately I found such annoying scene in BigBuckBunny at time 00:51 -- around bunny's left hand the background is moved/changed (old encode (http://msystem.waw.pl/x265/BigBuckBunny1500old.mkv)). The problem is mostly with rskip option, so I changed tune anime a little bit (subme += 2) and start encoding at preset palcebo -- I hope that quality will be acceptable at bitrate 1500.

Encoded samples with current tune anime at preset placebo (10-bit):
original1500.mkv (http://msystem.waw.pl/x265/original1500.mkv) -- grainy source after encoding is almost without grain (with dead/not moving grain). I don't like noise/grain so it is OK for me.
lighthouse1500.mkv (http://msystem.waw.pl/x265/lighthouse1500.mkv) -- the sky is without banding, OK for me.
ElephantsDream1500.mkv (http://msystem.waw.pl/x265/ElephantsDream1500.mkv) -- dark scenes looks a little bit worse, but it is acceptable for me.
Next samples in preparation...

[sneaker_ger]

If you need anime samples:
https://mega.nz/#!s0kQTbQQ!-6WkTrqXemhegSyjKwBteGYr9Iow_DRJwG3_d0pKr-4
https://mega.nz/#!VtdB2CLB!Y2Qwi6KivN87sl0ENjxJejPp3jDGjSGjvQiywopHcgU
https://mega.nz/#!5hc0VYpL!xWcGqQUmqxYq_Flzmx4RIclmZ5IBoxpXz21HKS6lYRM
https://mega.nz/#!w5tDnC5S!C9MmdwG0xrPtibWT907vWccjYq7uCX-TeurLKZmxvmQ (grainy)

[LigH]

Is this all Creative Commons material? And at least FullHD?

[sneaker_ger]

3/4 are 1080p, one is 480p.

[Ma]

Thanks for samples! They are not similar to BigBuckBunny.

[Gser]

I'm encoding HDR footage so I need to set max luma but I'm getting this error message
x265 [warning]: extra unused command arguments given <--max-luma=4000>
It defaults to 1000.

[Boulder]

Try --max-luma 4000.

[Gser]

Try --max-luma 4000.

Thanks that worked, funny how some commands work with "=" and others don't.

Also the command seems to have no effect, it is still showing max: 1000 cd/m2.

Setting min luma to 0.0050 also doesn't work, I'm guessing because the parameter is an integer.

[sneaker_ger]

--max-luma is for clipping input. It is usually not needed for HDR. You probably want to use the max/min luminance of "master-display (http://x265.readthedocs.io/en/default/cli.html#cmdoption-master-display)". (4000 is very high. Haven't seen such samples yet. Is this plausible for your source?)

[Gser]

--max-luma is for clipping input. It is usually not needed for HDR. You probably want to use the max/min luminance of "master-display (http://x265.readthedocs.io/en/default/cli.html#cmdoption-master-display)". (4000 is very high. Haven't seen such samples yet. Is this plausible for your source?)

Yes indeed it was mastered on a Dolby pulsar screen and it says so in the media information. This is the standard for Netflix or at least that's what I've been told. 4000 nits is also standard for Dolby vision. It works fine now just changed L(10000000,0) to L(40000000,5000).

[Midzuki]

x265.exe 2.7+8-613d9f443769

remove maxCTU size restriction in scaled save/load encodes

analysis: Introduce refine-intra level 4

use MV from analysis-save encode as MVP in load mode for refine-inter levels

Add max-ausize-factor option to control the maximum AU size defined in specification

Add reorderedPts to x265_picture to signal the reordered pts value of each picture in encode order.
Also shared the reordered pts value when analysis load is done by disabling lookahead.

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2513850#post2513850

[LigH]

#metoo

x265 2.7+8-613d9f443769 (https://www.mediafire.com/file/4o50tl4n753k7st/x265_2.7%2B8-613d9f443769.7z)

[brumsky]

Generally speaking, what has a greater effect on fine detail retention --tu-inter-depth or subme? It's for anime and I'm currently using --tu-inter-depth 4 subme 3 and --limit-tu 3. Would I get better results by upping subme and droping limit-tu to 4? Trying to find the best size\quality.

[Majorlag]

Generally speaking, what has a greater effect on fine detail retention --tu-inter-depth or subme? It's for anime and I'm currently using --tu-inter-depth 4 subme 3 and --limit-tu 3. Would I get better results by upping subme and droping limit-tu to 4? Trying to find the best size\quality.

The first part of your question asks what has better detail retention. the higher --subme value, the higher chance of fine detail retention. --tu-inter-depth does not effect detail retention as I understand it.

--tu-inter-depth is for compression or size. It is how much compression to shoot for. higher value, try to compress more. --limit-tu value effects how long to spend on compression target of --tu-inter-depth.

Hopefully I have read the command line options correctly. Try these set of options to see if they help you, it is what I use for anime "--qcomp 0.8 --rc-lookahead 30 --rc-grain --me 2 --subme 4 --no-strong-intra-smoothing --no-sao"