x265 HEVC Encoder

[nakTT]

For such ultra low resolutions you should stick with x264. x265 works best with FHD+ resolutions. 640x272 is less than DVD.
Thanks for the reply.

I was having the same thought to. However, based on results of quite an extensive test, x265 @ "Very Slow" preset (both 8 and 10 bit) is still noticeably better to the eyes than x264 @ "Placebo" preset (both 8 and 10 bit) even at such a low resolution and bitrate.

I do wonder if there are any settings besides a simple "Very Slow" preset (with Automated 2-Pass) that I have used that could help me further in term of visual quality without sacrificing the encoding speed too much. Hope you guys could share a thought on this.

Thank you in advance.:thanks:

This is possible, but under certain situations. I have done a lot of work with very low bitrate x265. It depends on what screen size you are viewing it on. For phone and tablet viewing, I have found even much lower bitrates to work fine.
For example, with stargate sg1, I keep the full resolution, 720x480, and encode with crf28 and nrintra 400, nrinter 400. I wouldnt normally use those, but on a small screen you cannot really see the detail loss.
Using 10bit is essential, it allows low bitrate and removes any banding due to that. The bitrates I have for s05e22 is only 119kbps! No macroblocking, etc... Heck I even just watch a bit on my 15.6 laptop screen and it is watchable. But not on a big screen, say 48".
Note this is on older versions of x265 (1.8+106), I havent tried new versions yet. I can provide full parameters if you wish.

Cheers,
Divxmaster
Thanks for the advice.

Seems like both of us share the same interest, at least as far as the very low bitrates and resolutions video encoding are concerned.

Speaking of the use of 10bit option in x265 encoding, does 12bit offer any advantage over the 10bit? I have done some testing but I can't really tell if there are any improvements in the subjective visual quality. Did you came across any situation where it does? Btw, im using "Very Slow" preset (with Automated 2-Pass) to keep the video within the selected average bitrate. Hope to hear from you soon.

Thank you in advance.:thanks:

You might find 360p (and aspect ratio equivalents) resolution (with possibly higher cfr to compensate for size) is worth it over 272p and 288p since x265 likes resolution more than texture at extreme low bitrates, and 360p seems to add just enough extra res to go from a 288p video that's "ewww" to "eh, I've seen worse."

You might even find 200 kbps or less tolerable.

720p at CFR of 28 or even higher can look surprisingly good (relatively speaking) especially the farther away/smaller the screen you watch it since when farther away grain/texture goes away and you focus more on edges of objects. But that setting will still usually use more bitrate than a "eh, I've seen worse" 360p resolution.

A main problem of higher resolution still comes down to x265 being so slow. 720p is a lot slower than 360p resolution. At extreme low bitrate, 720p may not be worth the encoding time and electricity over 360p resolution if you're just going for small size and tolerable quality.
Thanks for the reply.

I have done some further testing with 200kbps bitrate per your advice and it is indeed tolerable in quite a few use case.

As for a lower bitrates, I did quite a few testing using anime input with x264 (during its heyday) and found that even 150kbps bitrate is very much tolerable. However I have yet to give x265 a try with the same anime input. Do let me know if you have tried it with x265.

Thank you in advance.:thanks:

[divxmaster]

Hi NakTT,
here are the params I used.... Although I use low bitrate, I dont use low res... not necessary...

set param=--y4m --crf 28 --psy-rd 0.3 --limit-modes --limit-refs 3 --preset slow --b-intra --ref 5 --bframes 5 --max-merge 5 --nr-intra 400 --nr-inter 400 --sar %sar% --no-open-gop --min-keyint 23 --keyint 288 --deblock -1:-1

Note this is a year old, so not optimised for latest x265 but it still works great. For phone and tablet encodes only!! I havent tried 12 bit.
Cheers,
Divxmaster

[Barough]

x265 v2.4+27-e9e574bbed93 (http://www42.zippyshare.com/v/26AfVjXo/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 : HEVC encoder version 2.4+27-e9e574bbed93
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

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

[I]HDR10+ Enabled

[x265_Project]

HDR10 Enabled
I think you meant to say HDR10+.

HDR10 has been enabled in x265 for 2 years.

[Barough]

x265 v2.4+28-f850cdbe381c (http://www115.zippyshare.com/v/HSVMHt3K/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 : HEVC encoder version 2.4+28-f850cdbe381c
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

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

[I]HDR10+ Enabled

[eclipse98]

Back in Sept 2016 when we encoded our videos with x265 - took a bit of experimenting and we settled on pretty simple set-up with 2.0 build (slow preset, CRF26), 1080 60 fps footage at 6-8mbps.

Now, 9 months later with 2.4 build, exact same footage (same slow preset, CRF26 settings) encodes at around 10-15% higher bitrate - previously encoded 6000 kbps video is now in 6800-6900 kbps range.

Expectations were, of course, that given same CR we should see lower bit rate OR higher CR at same bit rate, so it's quite a disappointment to say the least.
Understandably presets have changed - but still one should expect improvements for the same CR.

What am I missing here ? Please advice ! :thanks:

[sneaker_ger]

Same CRF does not guarantee exact same quality with different settings and/or different x265 versions. If you want lower bitrate increase CRF a bit to compensate. If you want to compare old to new version encode to same bitrate using 2pass.

[Boulder]

The new lambda tables that were introduced recently increase the bitrate.

[LoRd_MuldeR]

The new lambda tables that were introduced recently increase the bitrate.

Increases bitrate for what?

If you use 2-Pass mode, then "old" and "new" lambda tables should produce the exactly same bitrate. And, if you use CRF mode, then you must not expect any particular bitrate anyway. It is likely that the introduction of the "new" lambda tables has changed the "meaning" of CRF values - once again. If, for example, the same CRF value results in a higher bitrate with "new" lambda tables, compared to "old" lambda tables, it means exactly nothing - because you are not taking into account at all how quality has changed at the same CRF value! Quite possibly, you can now (with "new" lambda tables) retain "similar" quality at a higher CRF value and therefore, in fact, get away with a lower bitrate...

So, if you want to do a "fair" comparison between the "old" and the "new" lambda tables, you have to compare clips with the exactly same average bitrate, i.e. clips created in 2-Pass mode. Then you can decide which one looks better.

(And once you have decided whether you prefer "old" or "new" lambda tables, you can re-adjust "your" CRF value for the new situation)

[LigH]

The "rate factor" is not a metric for a subjective quality impression. It is a measurable value for objective quality loss (~ difference between input and reconstructed video after quantization, possibly influenced by psycho-visual tweaks). Different encoding options may cause quality loss in different areas (e.g. frequency ranges), causing different bitrates despite the same CRF limit.

[Boulder]

Increases bitrate for what?

Quote Tom : "Note that a constant QP or CRF encode will probably be larger than your default encode"

If the user is using the exact same settings with the exact same video, the difference in the bitrate comes from the new lambda tables. My guess is that he has a lot of similar videos to encode and has found out the "average" bitrate level where they end up, and now the new version produces higher bitrates with the same settings.

What I personally did was that I adjusted CRF accordingly based on encoding the same couple of clips with the old and new lambdas (otherwise the same settings), so that the final result of the new version produces a slightly larger file.

[LoRd_MuldeR]

Quote Tom : "Note that a constant QP or CRF encode will probably be larger than your default encode"

If the user is using the exact same settings with the exact same video, the difference in the bitrate comes from the new lambda tables.

Yes. But it's more fundamental: If the user expects a certain fixed CRF value to result in a certain bitrate, then the user hasn't understood how CRF mode works. And, if the user thinks that comparing the bitrates that result from a certain fixed CRF value between different encoder configurations - may it be different lambda tables or something else - is meaningful (without considering how quality has changed as well!) hasn't understood how CRF mode works either.

It's all about compression efficiency, i.e. the "quality per bit" ratio. If some change (e.g. the "new" lambda tables) improves the compression efficiency, then it means that you can either get an improved quality at the same (average) bitrate, or that you can get a reduced (average) bitrate at the same quality. Conversely, if some change hurts the compression efficiency, then it means that you either get a worse quality at the same (average) bitrate, or that you get an increased (average) bitrate at the same quality. But, in any case, with CRF mode you simply do not know where exactly on the "quality/bitrate" curve you are going to end up. Therefore, it is quite possible that, even though the compression efficiency (i.e. the "quality per bit" ratio) has improved, the absolute bitrate - at a certain fixed CRF value - has increased as well! In the end, all you really know is that the absolute bitrate has changed and that the absolute quality (probably) has changed at the same time.

In order to draw a useful conclusion, at least one of the two factors - usually the average bitrate - needs to remain unchanged. Which means that you need to use 2-Pass mode, with same target bitrate, and then compare the resulting quality.

(In theory it is also possible to adjust the CRF value of each encode, until both configurations produce the exactly same quality and then compare the resulting bitrates. But this is much more difficult to do properly!)


What I personally did was that I adjusted CRF accordingly based on encoding the same couple of clips with the old and new lambdas (otherwise the same settings), so that the final result of the new version produces a slightly larger file.

IMO, the right method would be to adjust the CRF values until both - the "new" and the "old" lambda tables - produce the exactly same quality. Then, and only then, a comparison of the resulting bitrates would be meaningful.

But, because establishing "exactly same quality" is very difficult to do (probably would require a lot of ABX testing), it is much more easy to just encode in 2-Pass mode, at the same bitrate, and then decide which "flavor" looks better (if any).

[LigH]

x265 2.4+27-e9e574bbed93 (https://www.mediafire.com/file/406er6d04ob964k/x265_2.4%2B27-e9e574bbed93.7z) (merge with stable): more fields in rcStats and CSV file

[Atak_Snajpera]

x265_2.4+27-e9e574bbed93 (https://www.mediafire.com/file/406er6d04ob964k/x265_2.4%2B27-e9e574bbed93.7z) (merge with stable): more fields in rcStats and CSV file

Thanks. I have been waiting for your builds.

[x265_Project]

Back in Sept 2016 when we encoded our videos with x265 - took a bit of experimenting and we settled on pretty simple set-up with 2.0 build (slow preset, CRF26), 1080 60 fps footage at 6-8mbps.

Now, 9 months later with 2.4 build, exact same footage (same slow preset, CRF26 settings) encodes at around 10-15% higher bitrate - previously encoded 6000 kbps video is now in 6800-6900 kbps range.

Expectations were, of course, that given same CR we should see lower bit rate OR higher CR at same bit rate, so it's quite a disappointment to say the least.
Understandably presets have changed - but still one should expect improvements for the same CR.

What am I missing here ? Please advice ! :thanks:

As others have pointed out, the new lambda tables have changed the quality and bit rate you will achieve for a given QP or CRF value, with a given video title. To hit the same bit rate as before, you would have to adjust your QP or CRF value up a bit. We're confident, however, that you will achieve higher subjective quality at identical bit rates to your older encodes.

[Boulder]

IMO, the right method would be to adjust the CRF values until both - the "new" and the "old" lambda tables - produce the exactly same quality. Then, and only then, a comparison of the resulting bitrates would be meaningful.

But, because establishing "exactly same quality" is very difficult to do (probably would require a lot of ABX testing), it is much more easy to just encode in 2-Pass mode, at the same bitrate, and then decide which "flavor" looks better (if any).
That's why I trust the developers (and their QA people) and just adjusted the CRF to compensate. It was already enough work to initially find out the CRF level which will produce a good result with x265 without the bitrate skyrocketing :)

[pingfr]

As others have pointed out, the new lambda tables have changed the quality and bit rate you will achieve for a given QP or CRF value, with a given video title. To hit the same bit rate as before, you would have to adjust your QP or CRF value up a bit. We're confident, however, that you will achieve higher subjective quality at identical bit rates to your older encodes.

CRF 18 was mostly considered as the "sweet spot" with the 2.3 base, what would be it's equivalent now with 2.4?

[eclipse98]

As others have pointed out, the new lambda tables have changed the quality and bit rate you will achieve for a given QP or CRF value, with a given video title. To hit the same bit rate as before, you would have to adjust your QP or CRF value up a bit. We're confident, however, that you will achieve higher subjective quality at identical bit rates to your older encodes.

OK, that makes sense, we'll adjust CRF accordingly to hit similar bitrates. Appreciate everybody's input, keep up the good work !

Cheers !

[eclipse98]

Yes. But it's more fundamental: If the user expects a certain fixed CRF value to result in a certain bitrate, then the user hasn't understood how CRF mode works. And, if the user thinks that comparing the bitrates that result from a certain fixed CRF value between different encoder configurations - may it be different lambda tables or something else - is meaningful (without considering how quality has changed as well!) hasn't understood how CRF mode works either.

Thank you for the lesson! There was never an expectation that same CRF will result in same bitrate for different sources. Our goal was to maintain similar video quality across multiple (100+) videos. So CRF, rather than pre-defined bitrate, was an obvious (and faster) choice.

We observed bitrates from 2-10 mbps since our sources have quite significant variety, from wooded forests to almost desert-like conditions. Which is fine, as long as quality is "similar" (I understand it is very subjective).

Going forward we need to maintain that same "comparable" video quality. Clearly, recent changes in lambda tables (I have no clue what it is :)) did result in better quality and higher bitrates (for same settings) when compared to older encodes. So, it's back to the drawing board to find out which new CRF value will allow us to meet our goals.

Thanks again for all your help, Cheers !

[nakTT]

Hi NakTT,
here are the params I used.... Although I use low bitrate, I dont use low res... not necessary...

set param=--y4m --crf 28 --psy-rd 0.3 --limit-modes --limit-refs 3 --preset slow --b-intra --ref 5 --bframes 5 --max-merge 5 --nr-intra 400 --nr-inter 400 --sar %sar% --no-open-gop --min-keyint 23 --keyint 288 --deblock -1:-1

Note this is a year old, so not optimised for latest x265 but it still works great. For phone and tablet encodes only!! I havent tried 12 bit.
Cheers,
Divxmaster
Thanks for the reply.

I will give it a try and see if it works with the latest version of x265.

[Winston_Smith_101]

At 4.5.-8.5.2017 there were some speed optimizations in areas of the codec. Are there still more to be expected for the future?

[Midzuki]

x265.exe 2.4+36-de49a722b256

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2487738&viewfull=1#post2487738

[benwaggoner]

At 4.5.-8.5.2017 there were some speed optimizations in areas of the codec. Are there still more to be expected for the future?
x264 is still getting speed optimizations. x265 has years more ahead of it, I am sure. AVX-512 hardware is only just rolling out!

[Thunderbolt8]

arent there any real profiles or gui options to specify for x265 yet aside from the command line? at least in MeGUI there is nothing like that which is available for x264.

[benwaggoner]

arent there any real profiles or gui options to specify for x265 yet aside from the command line? at least in MeGUI there is nothing like that which is available for x264.



MeGUI just hasn't implemented a full GUI for x265 yet. Other products have much richer GUI options. It's all available via API.


Sent from my iPhone using Tapatalk

[x265_Project]

Apple adds HEVC support to iOS and MacOS ...https://www.cnet.com/news/apple-answers-iphone-storage-woes-with-smaller-photos-videos/

[LigH]

x265 2.4+36-de49a722b256 (https://www.mediafire.com/file/lrq9h0eb2jsdej6/x265_2.4%2B36-de49a722b256.7z)

New parameters:

--scale-factor <int> Specify factor by which input video is scaled down for analysis save mode. Default 0
--[no-]refine-intra Enable intra refinement for load mode. Default disabled
--[no-]refine-inter Enable inter refinement for load mode. Default disabled

[pradeeprama]

arent there any real profiles or gui options to specify for x265 yet aside from the command line? at least in MeGUI there is nothing like that which is available for x264.

You can give this consumer application a spin and see if it works out for you: https://x265.com/create-hevc-video/what-is-hevc/

[troica]

Is this x265 encoder using a C++ language (Microsoft Visual Studio)?

[sneaker_ger]

Yes, it's mostly written in C++. You can compile it using Visual Studio. For source code and compile instructions see: https://bitbucket.org/multicoreware/x265/wiki/Home

[troica]

Thank you!

Another question. If I want to know which source code lines do a specific thing (e.g. intracoding and intercoding mode of HEVC in the Encoder side), how do I run or debug each line? Is there a single step command? Thank you. It's for my thesis by the way.

[LigH]

Please read the documentation of your Visual Studio about how to use its debugger, how to set breakpoints on source lines, how to run a debugging session of a CLI application with command line parameters. That's just not the topic of this thread...

[troica]

I already know how to do that, what I mean is, is there some a way for us debuggers to see the actual modifications (e.g. in a video sequence) or do you really need to guess what parameters are being modified per line?

[LigH]

Debuggers usually allow to "watch expressions", so when a breakpoint is caught, you can usually inspect the value of specific variables at this point. And x265 is commercial-grade software with quite clean, verbose, and well documented sources, so you should find most variable and function names telling you something about their purpose.

[Natty]

in order to use --refine-mv we must have analysis = load and refine level = 10, but to use them we must disable mutlipass-opt-rps, multipass-opt-analysis and distortion. am i right ? :readrule:

[benwaggoner]

in order to use --refine-mv we must have analysis = load and refine level = 10, but to use them we must disable mutlipass-opt-rps, multipass-opt-analysis and distortion. am i right ? :readrule:
That sounds right. I'd like to better understand the pros/cons of each option.

One drawback to Refine Level 10 is HUGE log files. Typically a lot bigger than the encoded bitstream.

[Natty]

That sounds right. I'd like to better understand the pros/cons of each option.

One drawback to Refine Level 10 is HUGE log files. Typically a lot bigger than the encoded bitstream.

i get huge log (analysis) file even with refine level 5 to 9. i use 9. i cant use 10 though (along with refine-mv) because it needs new multipass options disabled. so i would like to know if those 3 multipass commands would produce a better result or refine-mv alone.

[Barough]

x265 v2.4+37-e75d5f5eeae3 (http://www23.zippyshare.com/v/4kIvr4MD/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.4+37-e75d5f5eeae3
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

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

[LigH]

x265 2.4+41-82ba8c85f8e9 (https://www.mediafire.com/file/papx661ixcl4cgn/x265_2.4%2B41-82ba8c85f8e9.7z)

AVX2 speedup for integral4h; add support for hdr-opt even when aq-mode is disabled; moved CSV feature into libx265; fix slicetype mismatch between analysis save and load modes

[LigH]

x265 2.4+61-28bbc349d170 (GCC 6.3.0) (https://www.mediafire.com/file/g6ix29o274vg6tm/x265_2.4%2B61-28bbc349d170.GCC630.7z)
x265 2.4+61-28bbc349d170 (GCC 7.1.0) (https://www.mediafire.com/file/ck8xpa432nk29cr/x265_2.4%2B61-28bbc349d170.GCC710.7z)

major overhaul of x86inc assembler routines (in sync with those in x264)

[pingfr]

Wow! Impressive.

If I'm not mistaken the commits between 2.4+41 and 2.4+61 are more or less all about code cleanup and optimization thus yielding (at least in theory) speedup gains. :)

Kudos to the devs, hope we get to see even more improvements in that grey area soon enough. :)

[Boulder]

Too bad it's only x86 :)

[LigH]

I'd assume changes to be relevant for x86 as well as x86-64. Which architecture do you prefer instead, PowerPC or ARM big.LITTLE? ;)

This set of patches is intended update x86inc.asm file. This synchronises x86inc with that of x264.

[Boulder]

I'd assume changes to be relevant for x86 as well as x86-64. Which architecture do you prefer instead, PowerPC or ARM big.LITTLE? ;)Hehe, I'm spoiled so I usually expect x86 or x64. Read too many times that x86 assembly is not the same as x64 :)

[LigH]

Of course, there are differences between "legacy" x86 and x86-64 a.k.a. AMD64 (e.g. twice as many and twice as wide registers); and in fact, using assembler optimizations is disabled for 32 bit builds with High Bit Depths because it would be inefficient to spend development time on a quite restricted platform (already FullHD resolutions will probably hit RAM limits for 32-bit processes). But I believe a few routines still exist in both variants.

[nevcairiel]

The entire point of the "x86inc.asm" framework developed for x264 and used by x265 as well as ffmpeg is to make it easier to write ASM code that works on both x86_32 and x86_64, as well as on various platforms (ie. Linux/Unix and Windows), because calling conventions also vary. That of course doesn't mean that all ASM code automatically works on both 32-bit and 64-bit, since 64-bit offers twice the amount of registers its often much easier to write complex ASM for 64-bit with double the registers to use.

[Magik Mark]

Just a clarification on "Analysis Mode"

If I want to to reuse the analysis data writen by an earlier encode of the same sequence, I have to execute "--analysis-mode load"?

Are there any other prerequisites? In "--multi-pass-opt-analysis" and "--multi-pass-opt-distortion", "cu-tree" needs to be off. I might be missing something. Just want to be sure

[Natty]

Just a clarification on "Analysis Mode"

If I want to to reuse the analysis data writen by an earlier encode of the same sequence, I have to execute "--analysis-mode load"?

Are there any other prerequisites? In "--multi-pass-opt-analysis" and "--multi-pass-opt-distortion", "cu-tree" needs to be off. I might be missing something. Just want to be sure
yes u need to turn them off sadly, even refine-mv requires those options to be disabled :(

[Kavitha]

Just a clarification on "Analysis Mode"

If I want to to reuse the analysis data writen by an earlier encode of the same sequence, I have to execute "--analysis-mode load"?

Are there any other prerequisites? In "--multi-pass-opt-analysis" and "--multi-pass-opt-distortion", "cu-tree" needs to be off. I might be missing something. Just want to be sure


-analysis-load isn't going to provide any benefit in pass 2 unless you use --analysis-save. Both the analysis modes require cutree, pmode to be off. Even if these options are 'on', x265 internally turns them off with a warning.

[santhoshini]

Just a clarification on "Analysis Mode"

If I want to to reuse the analysis data writen by an earlier encode of the same sequence, I have to execute "--analysis-mode load"?

Are there any other prerequisites? In "--multi-pass-opt-analysis" and "--multi-pass-opt-distortion", "cu-tree" needs to be off. I might be missing something. Just want to be sure

To use multi-pass-opt-analysis/multi-pass-opt-distortion the first pass must include --multi-pass-opt-analysis/multi-pass-opt-distortion. These
options do not rely on --analysis-save (it's a different type of analysis that is saved in the 1st pass) and they do not work in conjunction with analysis-save/analysis-load modes. multi-pass-opt-analysis/multi-pass-opt-distortion does not require cu-tree to be off but requires pmode/pme to be turned off.

We'll clarify the online documentation about these options.