x265 HEVC Encoder

[undfeatable]

Originally Posted by x265_Project

You can build x265 for MacOS. This will probably work better. than a Linux build. Try the nightly build of Handbrake... https://handbrake.fr/nightly.php

A person I am getting help from told me the only way to encode HDR video, which is my goal, is to do it on the command line no GUI like Handbrake.

I'm pretty sure I have it built for MacOS, at least inside my CMake application I go CMake.app -> Contents -> MacOS -> x265 -> build -> linux
I have the processors set up properly too. Here is an example of what it does:

yuv  [info]: 3840x2160 fps 24000/1000 i420p10 frames 0 - 199 of 200
raw  [info]: output file: TestC1.h265
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main 10 profile, Level-6.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features       : 3 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut       : 1 / 25 / 40
x265 [info]: Lookahead / bframes / badapt        : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : ABR-40000 kbps / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init    : 120000 / 120000 / 0.900
x265 [info]: tools: rect rd=4 psy-rd=0.30 rdoq=2 psy-rdoq=1.00 signhide tmvp
x265 [info]: tools: strong-intra-smoothing lslices=4 deblock sao
Segmentation fault: 11

Like I said though, it looks exactly the same whether it fails or goes through.

Originally Posted by undfeatable

A person I am getting help from told me the only way to encode HDR video, which is my goal, is to do it on the command line no GUI like Handbrake.

Why would it matter whether a command-line interpreter or a graphical user interface called x265? x265 doesn't care.

I run x265 from the command line very frequently, but won't hesitate to use a GUI application.

We can have our team look at this segmentation fault error if it persists. In the meantime, make sure you follow the instructions on BitBucket for compiling x265 for MacOS. https://bitbucket.org/multicoreware/x265/wiki/Home

[nima2010]

Originally Posted by Selur

as a small side note: x265 has an option to omit the SE info (--no-info)
+ may be updating mkvtoolnix might also help

yeah , i update mkvtoolnix to ver 8.6.1 now i can see media info of my x265 encode
there is something i want to ask , how i can decrease encoding time without losing quality? i dont care file size become the as x642 or bigger, i use x264 alot and encoding speed is good but for x265 is 1 fps ,it takes too much time to encode even for 720p file i decide to change setting but didnt use x265 alot and some setting are different with x264 or i didnt care to change them but for x265 i think situation is different ,by the way i just re-encode anime ,and i'm looking for good setting for big display ,like 40 inch TV ,plz guide me
is it necessary to update x265 when ver released? i barely update x264 but dont know about x265

[LigH]

The speed preset has less influence than the bitrate or quality (rate factor) target. For faster presets with a lower complexity, the encoder may not spend as much time searching for ways to spare bitrate, so the result may be a bit bigger, but the CRF mode will try to ensure that the loss of quality stays below a certain threshold.

The development of x265 is still very active, in contrast to x264 which is already rather "mature". You may not have to update often, but once in a while there are still quite important improvements in x265.

To improve results for real cartoons, x265 will probably implement a tuning like "--tune animation" in x264, but I am not sure if this already happened or is still scheduled.

[smok3]

@undfeatable: how is this one?
https://dl.dropboxusercontent.com/u/...bit_bronto.zip

x265 --version
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

Only did a very fast test like

x265 in.y4m --crf 21 out.mp4

and it didn't seqfault.

[nima2010]

Originally Posted by LigH

The speed preset has less influence than the bitrate or quality (rate factor) target. For faster presets with a lower complexity, the encoder may not spend as much time searching for ways to spare bitrate, so the result may be a bit bigger, but the CRF mode will try to ensure that the loss of quality stays below a certain threshold.

The development of x265 is still very active, in contrast to x264 which is already rather "mature". You may not have to update often, but once in a while there are still quite important improvements in x265.

To improve results for real cartoons, x265 will probably implement a tuning like "--tune animation" in x264, but I am not sure if this already happened or is still scheduled.

how i can findout tune animation added or not?
also about encode setting i always use crf mode it's really good for re-encoding anime, i use crf 18-22 but with x265 it takes along time looking for decreasing time ,i use slower preset ,bframe 6 rc lookahead 30 ref 3 ,with subme 3 i can encde 1.8-2.5 fps for 720p ,any better setting ?

[sneaker_ger]

Originally Posted by nima2010

how i can findout tune animation added or not?

In doubt just test it and see if there is an error message or look into the documentation. (--tune animation does not exist)

Originally Posted by nima2010

also about encode setting i always use crf mode it's really good for re-encoding anime, i use crf 18-22 but with x265 it takes along time looking for decreasing time ,i use slower preset ,bframe 6 rc lookahead 30 ref 3 ,with subme 3 i can encde 1.8-2.5 fps for 720p ,any better setting ?

Try adding --limit-refs 3 and --limit-modes. These are new options still in testing and not yet added to the presets. They improve speed significantly while hopefully only marginally reducing compression efficiency:
http://forum.doom9.org/showpost.php?...postcount=2905

I the long-term I'd not use too many options because you might miss future improvements of the presets. Preset slower uses rc-lookahead 30, ref 3 and subme 3 anyways. I guess limit-refs and limit-modes are among those options that will be incorporated into the presets in the not so distant future.

If it's still too slow do the obvious and switch to preset "slow", "medium", "fast" etc. That's the reason they exist.

[Motenai Yoda]

@vivian my bad, but it's always a sample, isn't rappresentative of the entire video
btw what pingfr want to do make me think about an absolute signal-noise difference percentile

@nima2010 it isn't
try with more reference and limit-ref 3 and limit-mode

[FranceBB]

@nima2010... basically what a codec does is removing spacial redundancy and, to do that, it uses a transform to transform "blocks of pixels" into coefficients (that's why you see blocking artifacts with low-bitrate: the transform is not applied to the whole picture because of a complexity matter; they tried with JPEG2000). Then, these coefficients are passed to the quantiser in order to get rid of high frequencies (that are not important for the human vision) and to save space.
The better transform available in terms of compression efficiency is the KLT (Karhunen–Loève transform), but its drawback is that it's an highly complexity transform, so they decided to use the DCT (Discrete Cosine transform) in x264 because it has a relatively good compression efficiency.
What x265 does, instead, is using both DCT and KLT (NOT simultaneously: it automatically switch between DCT and KLT depending on which blocks it has to encode) in order to compress images in a better way than the DCT alone, without increasing complexity too much.
That said, it's pretty normal that x265 takes more time to encode than x264 with the same settings.
Anyway, x265 is able to use multiples processors and its development is going on actively, so I strongly suggest to keep it update.
Besides, x265 is a way better than x264 in terms of compression and the initial designed target of a 50% bitrate reduction has been fulfilled.
As soon as I'll have time, I'm gonna run an encode on a xeon phi coprocessor using both x264 and x265 in order to see if x265 will be able to fully use all the cores and to demonstrate that, probably, x264 will not be able to use them.

Originally Posted by sneaker_ger

Try adding --limit-refs 3 and --limit-modes. These are new options still in testing and not yet added to the presets. They improve speed significantly while hopefully only marginally reducing compression efficiency:
http://forum.doom9.org/showpost.php?...postcount=2905

I the long-term I'd not use too many options because you might miss future improvements of the presets. Preset slower uses rc-lookahead 30, ref 3 and subme 3 anyways. I guess limit-refs and limit-modes are among those options that will be incorporated into the presets in the not so distant future.

Yes. limit-refs and limit-modes will be added to updated presets as soon as we are able to complete our testing (delayed a week due to flooding in Chennai).

[undfeatable]

Originally Posted by smok3

@undfeatable: how is this one?
https://dl.dropboxusercontent.com/u/...bit_bronto.zip

x265 --version
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

Only did a very fast test like

x265 in.y4m --crf 21 out.mp4

and it didn't seqfault.

Negative, it still happens randomly

yuv  [info]: 3840x2160 fps 23976/1000 i420p10 frames 0 - 199 of 200
raw  [info]: output file: HDRTest.h265
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main 10 profile, Level-6.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features       : 3 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut       : 1 / 25 / 40
x265 [info]: Lookahead / bframes / badapt        : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : ABR-40000 kbps / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init    : 120000 / 120000 / 0.900
x265 [info]: tools: rect rd=4 psy-rd=0.30 rdoq=2 psy-rdoq=1.00 signhide tmvp
x265 [info]: tools: strong-intra-smoothing lslices=4 deblock sao
Segmentation fault: 11

I just download Handbrake, won't be able to test much for at least a week or so, but Ill let y'all know.

[benwaggoner]

Originally Posted by undfeatable

A person I am getting help from told me the only way to encode HDR video, which is my goal, is to do it on the command line no GUI like Handbrake.

I can't speak to Handbreak specifically (it's more of a heartbreak for me whenever I've tried to us it for anything mildly interesting ).

But there are a bunch of somewhat esoteric parameters that need to be set for a proper HDR-10 bitstream. Looking at a test file I did a few months ago:

--colorprim bt2020
--transfer 16
--colormatrix bt2020nc
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,0)"
--max-cll "1000,274"
--chromaloc 2

And, of course, you'll need to know what your master-display, MaxCLL, and MaxFALL values are for your content.

And you'll need to have a >=10-bit source that's already in the SMPTE 2084 PQ space, not gamma.

Also, I note you're targeting Level 5.1. AFAIK, there aren't any existing HEVC Main10 decoders that support beyond Level 5.1. Which can do 2160p60 !

[Ma]

Originally Posted by undfeatable

Negative, it still happens randomly

yuv  [info]: 3840x2160 fps 23976/1000 i420p10 frames 0 - 199 of 200
raw  [info]: output file: HDRTest.h265
x265 [info]: HEVC encoder version 1.8+129-e2e507ffe752
x265 [info]: build info [Mac OS X][clang 7.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
...

If the same binary works with SSE4.2 CPU and hangs with AVX2 CPU, you can add '--asm AVX' option or '--asm SSE4.2' option and retest.

[Vesdaris]

So, I've been playing with medium preset and crf/psy-rd\rdoq\psyrdoq\loo filter values trying to preserve as much details as possible compared to the original and making encoded video smaller than x264(x264 hi10p, crf18 very slow preset) one and I got a question- Is it even possible?

We have three files :
A - original
B- x264 hi10p, crf18, very slow preset (subme-9 instead of 10 coz I don't like how it make things look)
C- x265 main10 medium(slow doesn't help things just makes encoding very slow and possibly but now always smaller size-wise) with tweaked differently crf\psy-rd\rdoq\psyrdoq\loo filter values.

A and B are identical visually. However, no matter how much I tried I couldn't get x265 encode look the same as the original\x264.There were always small details missing here and there, small blur here and there, you name it. These issues were prolly not that obvious when watching it in motion but clearly distinguished when comparing png screenshots(original\x264\x265).

I even got really close to x264 bitrate-wise and x264 still looked more "clean".And there was no point increasing bitrate any further coz ,well, why bother if x264 hi10p does it all and faster.

What settings do you guys use to make x265 encode as close to the original'x264hi10p as possible but still keeping it smaller in size?

[luigizaninoni]

you might try these: (good for sd; for hd you had better increase crf, max-tu-size, merange, ctu)

--crf 17.5 --preset slow --output-depth 10 --rd 5 --ctu 16 --max-tu-size 8 --limit-refs 1 --tu-intra-depth 3 --tu-inter-depth 3 --rdoq-level 1 --no-rect --b-intra --qg-size 16 --qcomp 0.71 --subme 5 --merange 32 --max-merge 4 --weightb --bframes 10 --rc-lookahead 60 --ref 5 --min-keyint 1 --keyint 400 --no-strong-intra-smoothing --rdpenalty 2 --deblock -2:-2 --psy-rd 0.7 --psy-rdoq 1.7 --no-sao

[LigH]

*TILT*

With so many single options, does any "preset" still make sense, or are all contained options superseded anyway?

And could you explain for each of them why they would be better than the preset defaults?

[Vesdaris]

Originally Posted by luigizaninoni

you might try these: (good for sd; for hd you had better increase crf, max-tu-size, merange, ctu)

--crf 17.5 --preset slow --output-depth 10 --rd 5 --ctu 16 --max-tu-size 8 --limit-refs 1 --tu-intra-depth 3 --tu-inter-depth 3 --rdoq-level 1 --no-rect --b-intra --qg-size 16 --qcomp 0.71 --subme 5 --merange 32 --max-merge 4 --weightb --bframes 10 --rc-lookahead 60 --ref 5 --min-keyint 1 --keyint 400 --no-strong-intra-smoothing --rdpenalty 2 --deblock -2:-2 --psy-rd 0.7 --psy-rdoq 1.7 --no-sao

Thanx but I guess I forgot to mention one important detail. Encoding speed mustn't be that of a dying turtle lol as in 6-8fps is a min.(3770k@4.5)
PS crf17.5? Even lower than x264 to get supposedly the same quality? I'm testing these settings on a sample file and judging by the bitrate the file size will be too close(4700-4800 vs 5200+) to x264 hi10p size. So, no point, especially taking into account absolutely ridiculous encoding speed....even if I set crf higher than 17.5 encoding speed won't change.

[luigizaninoni]

@ligh: tune-film does not exist at the moment, so this would be a suggestion for tune-film SD. imho there should also be tune-film HD and UHD (different from one another). I sure won't comment on each parameter (for some of them I have only a very rough idea of what they do), but I can say that no-rect is a necessity at the moment, because rect and amp give practically no benefit, and speed is 40% slower. Useless atm. Merange 32 is more than enough for SD, sure it could be increased for HD. Keyint 400 is a little trick to gain a bit of compression in static scenes, maybe it saves 1% or 2% bitrate. Defaults for psy-rd and psy-rdoq are too low (0.30 and 1.00 if I remember correctly), they definitely should be increased (how much exactly, remains to be seen).

@Vesdaris: I easily attain 11-12 fps on my i7-4770s on SD, it is an acceptable speed in my opinion. I agree that with HD it is very slow.

[burfadel]

Originally Posted by luigizaninoni

@ligh: tune-film does not exist at the moment, so this would be a suggestion for tune-film SD. imho there should also be tune-film HD and UHD (different from one another). I sure won't comment on each parameter (for some of them I have only a very rough idea of what they do), but I can say that no-rect is a necessity at the moment, because rect and amp give practically no benefit, and speed is 40% slower. Useless atm. Merange 32 is more than enough for SD, sure it could be increased for HD. Keyint 400 is a little trick to gain a bit of compression in static scenes, maybe it saves 1% or 2% bitrate. Defaults for psy-rd and psy-rdoq are too low (0.30 and 1.00 if I remember correctly), they definitely should be increased (how much exactly, remains to be seen).

@Vesdaris: I easily attain 11-12 fps on my i7-4770s on SD, it is an acceptable speed in my opinion. I agree that with HD it is very slow.

I totally agree about rect, amp, and merange. A while ago I mentioned to Stax to put in a variable merange into Staxrip, which was done (at a basic level). Maybe the same thing could be done with x265. That is, if the input resolution is say, 864x480 that the merange is set to say, 25, and scale that up to 57 the higher the resolution you go, or at least to a value that gives you the best quality without penalty of encode time.

At the moment if you think of it, at least the way I see it, having a fixed rate of 57 means that it is actually significantly greater at SD resolution (and effectively be 'placebo' at 57) than it is at UHDTV resolution.

I also agree with the psy-rd statement (not so sure about psy-rdoq). I have mine set at 0.5 which I think is better. Realistically though, even 0.5 may be too conservative.

With these settings:
--crf 21 --output-depth 10 --limit-refs 1 --tu-intra-depth 3 --early-skip --b-intra --aq-mode 3 --qg-size 16 --subme 3 --me star --merange 25 --max-merge 5 --weightb --bframes 6 --rc-lookahead 40 --ref 6 --keyint 600

I am currently getting around 26-28 fps encoding material of 1280x720 to 864x480. That is actually what it is getting running in the background as I type this. This is using Staxrip with the latest 1.8+132 x265, latest ffmpeg, AVX build, using the latest l-smash-works, avisynth+, and the filters vinverse2, deveed, f3kdb, and using blackmanresize with 8 taps.

This is on a i5-3570K at 4.3 GHz, so isn't using AVX2.

I found that setting --tu-intra-depth 3 gave slightly better quality with no noticeable performance penalty. I also found adding --early-skip gave noticeably better performance without a quality or file size hit (or so fractionally slight the speed gain far outweighed any 'loss'). --max-merge 5 is probably overkill, but setting it higher than default I believe gives a small quality/and or file size improvement with only a small penalty in performance. Basically --qg-size 16 is a must, and I believe --aq-mode 3 is as well . Adding --limit-refs 1 was certainly worth it, I did try the higher ones but the performance gains were only small compared to --limit-refs 1, I didn't see the need to use anything higher.

I found --me-star to be quite surprisingly good both quality an speed wise, at least for what I've been encoding at non-UHDTV resolutions. The setting --me-star actually kind of makes hex and umh modes redundant seeing as your get hex speeds with what appears to be umh quality.

So, with those settings I not only get better quality than the default settings, but I believe it is also faster!

[Blowis]

Originally Posted by Vesdaris

So, I've been playing with medium preset and crf/psy-rd\rdoq\psyrdoq\loo filter values trying to preserve as much details as possible compared to the original and making encoded video smaller than x264(x264 hi10p, crf18 very slow preset) one and I got a question- Is it even possible?

We have three files :
A - original
B- x264 hi10p, crf18, very slow preset (subme-9 instead of 10 coz I don't like how it make things look)
C- x265 main10 medium(slow doesn't help things just makes encoding very slow and possibly but now always smaller size-wise) with tweaked differently crf\psy-rd\rdoq\psyrdoq\loo filter values.

A and B are identical visually. However, no matter how much I tried I couldn't get x265 encode look the same as the original\x264.There were always small details missing here and there, small blur here and there, you name it. These issues were prolly not that obvious when watching it in motion but clearly distinguished when comparing png screenshots(original\x264\x265).

I even got really close to x264 bitrate-wise and x264 still looked more "clean".And there was no point increasing bitrate any further coz ,well, why bother if x264 hi10p does it all and faster.

What settings do you guys use to make x265 encode as close to the original'x264hi10p as possible but still keeping it smaller in size?

After several tests I managed to approach the x264.
To do that I use medium profile I change ctu = 16 psy-rd = 1.00 rdoq-level = 2 psy-rdoq = 1.10.