x265 HEVC Encoder

[LigH]

No, development of "incomplete" RD modes and AQ in conjunction is progressing... I did not have crashes in earlier tests, but encoding artefacts; AQ use{s|d} to rely on complete RD analysis data.

[xooyoozoo]

Tested a simple 16s clip cut from a documentary BluRay and x264 2377 and x265 @2ba6c26. Used placebo presets and matched x264's 2pass bitrate to x265's default CRF (28) with aq-mode 1. Bitstreams and side-by-side comparison (https://drive.google.com/folderview?id=0BzAA-H5x8NKTelUtRHNrT3kzUms&usp=sharing).

I know that things are still incomplete, but at the very least, AQ seems to be doing its thing and there's no longer that fuzzy 'reference' look I remember from the HM.

[nakTT]

Tested a simple 16s clip cut from a documentary BluRay and x264 2377 and x265 @2ba6c26. Used placebo presets and matched x264's 2pass bitrate to x265's default CRF (28) with aq-mode 1. Bitstreams and side-by-side comparison (https://drive.google.com/folderview?id=0BzAA-H5x8NKTelUtRHNrT3kzUms&usp=sharing).

I know that things are still incomplete, but at the very least, AQ seems to be doing its thing and there's no longer that fuzzy 'reference' look I remember from the HM.
What is the version of x265 used?

[x265_Project]

We are getting close to a stable 0.6 version. If you are running builds from the development tip you will notice that we just updated the performance preset settings, providing better results and a better distribution of values (along the speed vs. efficiency curve). We'll publish a new Evaluator's Guide with the new values shortly.

Tom

[nakTT]

We are getting close to a stable 0.6 version. If you are running builds from the development tip you will notice that we just updated the performance preset settings, providing better results and a better distribution of values (along the speed vs. efficiency curve). We'll publish a new Evaluator's Guide with the new values shortly.

Tom

How do I know which is a development tip and which is not? Thanks.:thanks:

[Procrastinating]

Tested a simple 16s clip cut from a documentary BluRay and x264 2377 and x265 @2ba6c26. Used placebo presets and matched x264's 2pass bitrate to x265's default CRF (28) with aq-mode 1. Bitstreams and side-by-side comparison (https://drive.google.com/folderview?id=0BzAA-H5x8NKTelUtRHNrT3kzUms&usp=sharing).

I know that things are still incomplete, but at the very least, AQ seems to be doing its thing and there's no longer that fuzzy 'reference' look I remember from the HM.
Granted the x264 video could probably have been better tuned, but that does look like quite a measurable improvement! I have some free time on my hands, so I might try comparing some anime credits or something.

Another question, is 16bpp functional? Ie, can I input and/or output 10-bit video?

[x265.cc]

What is the version of x265 used?

"x265 @2ba6c26" ~ x265_0.5+610-2ba6c26c9feb

How do I know which is a development tip and which is not? Thanks.:thanks:

Look at the "stable" tag at https://bitbucket.org/multicoreware/x265/commits/all. As you can see the "stable" versions are normal "development" version which are meant to be stable.

Another question, is 16bpp functional? Ie, can I input and/or output 10-bit video?

AFAIK it can currently only output 16-bit hevc files (you probably should try it yourself), the current 16bpp version should work but is really incomplete and slow (in comparison to the 8bpp version).

We are getting close to a stable 0.6 version.

Can you tell me if there is any special usage case for the stable version?

[James Freeman]

Bitstreams and side-by-side comparison (https://drive.google.com/folderview?id=0BzAA-H5x8NKTelUtRHNrT3kzUms&usp=sharing).


Holly Cow, what a difference. :eek:
I don't know what the PSNR or SSIM are, but it sure looks almost twice as good.

And its only the beginning.

[JEEB]

AFAIK it can currently only output 16-bit hevc files (you probably should try it yourself), the current 16bpp version should work but is really incomplete and slow (in comparison to the 8bpp version).
The "16bpp" part only notes that the variables that keep the intermediate (and final) values are 16bit. The HEVC specification only specifies algorithms up to 14 bits, and the current HEVC profiles only support 8-10 bits. The encoding itself is 10 bits.

You are correct about it being very much slower than the 8bit version, of course ;)

[MasterNobody]

Tested a simple 16s clip cut from a documentary BluRay and x264 2377 and x265 @2ba6c26. Used placebo presets and matched x264's 2pass bitrate to x265's default CRF (28) with aq-mode 1. Bitstreams and side-by-side comparison (https://drive.google.com/folderview?id=0BzAA-H5x8NKTelUtRHNrT3kzUms&usp=sharing).

I know that things are still incomplete, but at the very least, AQ seems to be doing its thing and there's no longer that fuzzy 'reference' look I remember from the HM.
I would recommend next time when you will do x264 compression at such low bitrates that it is already blocking to disable PsyRD (--psy-rd 0). Because imho PsyRD is only visually useful when you have enough bitrate for it and at low bitrates it can harm quality. I doubt it will change this comparison significantly but should make x264 less blocky.

[x265.cc]

The "16bpp" part only notes that the variables that keep the intermediate (and final) values are 16bit.

hehe, thanks for clarifying this :goodpost:


Probably i should had to check the "input-depth" parameter first :D

[x265_Project]

We've updated x265's performance presets, providing better performance and compression efficiency (quality at any given bitrate) for most presets. We've also worked to provide a good range of values along the speed vs. efficiency curve.

I've posted a new x265 Evaluator's Guide (https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%20Nov%2029%202013.pdf).

As always, constructive feedback is welcomed.

Tom

[filler56789]

Any GOOD reason why now the PDF is "secured" (i.e., Content Copying, Page Extraction and Commenting now are "not allowed")? :sly:

[fumoffu]

I have been looking in the preset changes in the code before you posted updated guide and noticed possible mistake.
by default bpyramid is being set to 2 while the only documented values are 0 and 1
param->bpyramid = 2
and all other presets are setting it back to 1 except slower, veryslow, placebo
if bpyramid 2 exists and does something to improve quality it's strange that default has it set to 2 but slow to 1

btw. default keyframeMin = 0 seems a bit low ;) is there some other mechanism that prevents too frequent I frames in fast changing images? is there a switch to change this like --min-keyint ?

Also if anyone knowledgeable is bored ;) and could explain what some of those options do I would be very happy:
--max-merge - what are we merging? I'm guessing partitions but I would love to know more how and when this works.
--early-skip - what are we skipping?
--fast-cbf - what does cbf stands for again?

[x265.cc]

what does cbf stands for again?

coded block flag


--early-skip - what are we skipping?


is Early skip detection for HEVC

http://phenix.it-sudparis.eu/jct/doc_end_user/documents/7_Geneva/wg11/JCTVC-G543-v3.zip could be useful for you

[fumoffu]

Thanks, l was wondering what is the difference between that and --tskip
Hopefully someday everything will be as nicely documented/explained as in X264 Settings - MeWiki :)

[x265_Project]

I have been looking in the preset changes in the code before you posted updated guide and noticed possible mistake.
by default bpyramid is being set to 2 while the only documented values are 0 and 1
param->bpyramid = 2
and all other presets are setting it back to 1 except slower, veryslow, placebo
if bpyramid 2 exists and does something to improve quality it's strange that default has it set to 2 but slow to 1

Good eye. It's my mistake (I wrote the patch to revise the defaults and preset values). I fixed this in the documentation but it needs to be fixed in the code. I've sent another patch to our development team to review and commit. Of course, since bpyramid is a logical value, any non-zero value is true, and so this bug is benign.

Tom

[Procrastinating]

The "16bpp" part only notes that the variables that keep the intermediate (and final) values are 16bit. The HEVC specification only specifies algorithms up to 14 bits, and the current HEVC profiles only support 8-10 bits. The encoding itself is 10 bits.

You are correct about it being very much slower than the 8bit version, of course ;)

So 16bpp output is storing 10-bit data in 16-bit variables? I'm guessing there isn't any redundancy/that x264 also does something similar?
Leading on from that, obviously it's much slower, but is it more space-efficient than 8bpp? Or rather, is there any reason to test/compare 16bpp/10-bit to 8bpp at this stage?

I plan on comparing some anime credits, so I want to make sure I am making fair comparisons to default/fan-tuned encodes(8-bit vs 8-bit, or 10-bit vs 10-bit, or all vs all). Just looking through different ones at the moment to find problem-cases(difficult to compress but not because of noise)

[LoRd_MuldeR]

So 16bpp output is storing 10-bit data in 16-bit variables? I'm guessing there isn't any redundancy/that x264 also does something similar?

The smallest addressable unit of memory (aka "Byte") is 8-Bit on pretty much any modern computer. So if you store a value in memory, you need to use at least one byte (8-Bit). Even booleans usually take one byte! But if the data is bigger than one byte, you will need to use two bytes (16-Bit) to store the value - even if the value is only 10, 12 or 14 bits in size. The "unused" bits will usually be padded with zero's. For values bigger than 16-Bit you'd use 24-Bit or even 32-Bit. And so on...

Surely, one could "pack", for example, 4 values à 10-Bit into 5 consecutive bytes, in order to eliminate that overhead. But then these values won't be addressable directly anymore. You would need to use some bit-operation magic to store/read your values, which usually is too complex and too slow. So, most of the time, you simply accept the overhead of storing a 10-Bit (12-Bit, 14-Bit) value in a 16-Bit variable.

[x265_Project]

The smallest addressable unit of memory (aka "Byte") is 8-Bit on pretty much any modern computer. So if you store a value in memory, you need to use at least one byte (8-Bit). Even booleans usually take one byte! But if the data is bigger than one byte, you will need to use two bytes (16-Bit) to store the value - even if the value is only 10, 12 or 14 bits in size. The "unused" bits will usually be padded with zero's. For values bigger than 16-Bit you'd use 24-Bit or even 32-Bit. And so on...

Surely, one could "pack", for example, 4 values à 10-Bit into 5 consecutive bytes, in order to eliminate that overhead. But then these values won't be addressable directly anymore. You would need to use some bit-operation magic to store/read your values, which usually is too complex and too slow. So, most of the time, you simply accept the overhead of storing a 10-Bit (12-Bit, 14-Bit) value in a 16-Bit variable.
This is a very good explanation. To this I would add that using the word "storing" (as procrastinating did in the original question) might be a bit misleading. Yes, we are storing these 10, 12 or 14 bit samples in 16 bit values, but only during the few milliseconds that we are processing those video samples in a CPU or GPU.

All modern video encoding standards use some form of lossless data compression (entropy encoding) which converts symbols into the final bitstream. HEVC uses context adaptive binary arithmetic coding (CABAC) to losslessly compress syntax elements to encoded bits. AVC uses CABAC or CAVLC. So, when the video is stored on a hard drive or other storage medium, we don't end up with all of those extra zeros padding the ends of our samples. But when we are encoding or decoding video, we need to process uncompressed video samples with standard CPUs or GPUs, and for this we need to move and perform operations on the uncompressed data in standard-sized units (data words). Computer processors can process data in 8 bit words, 16 bit words, 32 bit words, and for some 64 bits or larger. We can also process multiple words of data with a single instruction (this is called Single Instruction, Multiple Data, or SIMD), allowing us to pack eight 8-bit data words into a single 64 bit register, performing operations on all 8 of these data words with one instruction. When we are processing 10 bit video, we have to use 16 bit words to move and operate on these 10 bit values, and so we can only process half as many data words per clock cycle. This is why we see a big performance penalty the moment we start trying to process video that has more than 8 bits/sample. Once we switch over to using 16 bit words for every video sample, we will only move and operate on half as much data per clock cycle.

So, again... when stored in a video file, thanks to entropy encoding (CABAC, CAVLC, etc.), 10 bit/sample video is not twice the size of 8 bit/sample video. But when we are encoding, decoding or performing any intermediate processing (scaling, color space conversion, frame rate conversion, etc.) on 10 bit/sample video, we will see a big drop in performance on standard off-the-shelf CPU and GPU hardware (versus 8 bit/sample video). Of course, if you are designing an Application Specific Integrated Circuit (a hardware encoder/decoder/video processor), you can design it to operate on data of any width necessary, and so you aren't faced with the same limitation.

I hope this helps.

Tom

[Procrastinating]

Reading into that, I wonder if recent advancements in FPGA technology and openCL could allow for the development of cost effective ad hoc h265 encoders/decoders with the DSP capability of a software application.

[x265_Project]

Reading into that, I wonder if recent advancements in FPGA technology and openCL could allow for the development of cost effective ad hoc h265 encoders/decoders with the DSP capability of a software application.

There are many good possibilities when it comes to accelerating HEVC encoding.

[easyfab]

@x265_Project

If possible, can we have a more accurate SSIM number, 4 or 5 decimal places or perhaps add db like in x264 ?

[x265_Project]

@x265_Project

If possible, can we have a more accurate SSIM number, 4 or 5 decimal places or perhaps add db like in x264 ?

My initial reaction is that this would be an easy change if it only involves the reporting of the number and not the calculation. I developed a similar patch (fixing the SSIM reporting in the log file) over the weekend.

diff -r 833d78aaf71e source/encoder/encoder.cpp
--- a/source/encoder/encoder.cpp Fri Nov 29 16:40:42 2013 +0530
+++ b/source/encoder/encoder.cpp Fri Nov 29 15:49:01 2013 -0800
@@ -570,7 +570,7 @@
else
fprintf(m_csvfpt, " -, -, -, -,");
if (param.bEnableSsim)
- fprintf(m_csvfpt, " %.2f,", stats.globalSsim);
+ fprintf(m_csvfpt, " %.3f,", stats.globalSsim);
else
fprintf(m_csvfpt, " -,");


Tom

[easyfab]

Thanks Tom, that's what I want.

For info are there several possible calculations ? It's a standard formula, right ?

[mandarinka]

For comparing different encoders, you should probably use a standalone tool.
For example x264 IIRC did some shortcuts (not deblocking non-reference Bframes or something like that) during the calculations, and it is possible x265 does it similarly. Using a standalone tool in any case gets rid of such variances.

[fumoffu]

I was wondering, are there any plans for adjustable deblock strength and threshold like in x264?

[x265_Project]

Release Notes...

x265 0.6 is a regularly scheduled release

There were large improvements in compression efficiency since 0.5, mostly a result of the completion of weightp and b-pyramid. There is also a large amount of new assembly code; replacing most of the compiler intrinsic functions and adding coverage for some new primitives.


= New Features =
* CLI reads input video from stdin
* Main10 profile is enabled, requires a HIGH_BIT_DEPTH build
* weightp is now complete enough to be enabled by default
* performance presets have been defined, matching x264 preset names
* b-pyramid (hierarchical B frames) now supported
* Constant Rate Factor rate control is considered stable
* Adaptive Quantization introduced (experimental)

Adaptive Quantization is still considered experimental. We are not always seeing the expected improvements to SSIM when it is enabled, and thus it is still not enabled by default.


= API Changes =
* x265_nal data members renamed
* x265_picture now has colorSpace member
* --weightp enabled by default
* default parameters now match our medium preset
* new x265_param_default_preset() method for assigning preset and tune
* new x265_param_alloc() and x265_param_free() methods for version safety
* new x265_picture_alloc() and x265_picture_free() methods for version safety

The public data structures have changed enough that apps compiled against previous versions of x265 must be recompiled to use x265 0.6. We are taking steps to add version safety to the public interface. If you use the new alloc/free methods for the param and picture structures, and use x265_param_parse() to set param values by name, you will likely not have to recompile your application to dynamically link against later releases of x265.


= New Command Options =
* --y4m overrides detection of Y4M input stream, ex: x265 --y4m - out.hevc < vid.y4m
* --version long option alias for -V
* -p/--preset sets performance preset
* -t/--tune sets parameter tuning
* --[no-]b-pyramid enabled by default
* --input-csp color space parameter, only i420 is supported in this release
* --crf constant rate factor rate control
* --aq-mode and --aq-strength

See x265 --help for more details


= Upcoming improvements =
* motion compensated weightp analysis (using lookahead data)
* CU-tree (MBtree adapted from x264)
* VBV rate control
* assembly for HIGH_BIT_DEPTH builds

[foxyshadis]

Now this is good news. The rate of change has been incredible over the past few months, especially in getting assembly written, and I've seen the patches coming for CUtree already. Great work! I'll probably take this and see how it performs on a real video soon.

[x265_Project]

Now this is good news. The rate of change has been incredible over the past few months, especially in getting assembly written, and I've seen the patches coming for CUtree already. Great work! I'll probably take this and see how it performs on a real video soon.

Thanks Foxyshadis. The development team has definitely ramped up to a good pace, and we're very pleased with the results of their hard work. Still lots more work to do, but I think we're on track.

Tom

[fumoffu]

btw. 0.6 Release Notes, since it hasn't been mentioned:
--rd can now have values from 1 to 6 (previous value 2 is now 5,6)

from my tests Adaptive Quantization works correctly with rd>=4

[benwaggoner]

Release Notes...

x265 0.6 is a regularly scheduled release

* Adaptive Quantization introduced (experimental)

Adaptive Quantization is still considered experimental. We are not always seeing the expected improvements to SSIM when it is enabled, and thus it is still not enabled by default.
If your AQ is based on the one from x264, it is considerably more advanced and subjectively correlated than SSIM. If it is on, you will probably see a bigger gap between SSIM and PSNR. But the only really relevant way to check is subjective comparison.

From my experimenting in the last couple of weeks, it did seem to provide a significant visual improvement, although I wasn't doing comprehensive testing.

[LigH]

SSIM is not able to measure a subjective improvement. So don't be sad about not getting a perfect similarity based on a technical metric; the metric will be the less reliable value, compared to an ABX test with hundreds of probands.

[sneaker_ger]

I'm having some difficulty using x265. I tried a 10 Bit encode using a build from x265.cc (64bit, 16bpp, 1d2d60f4eb81, mingw). Here's the command-line I used:
x265 - --input-res 1920x800 --fps 24000/1001 --input-depth 10 --crf 18 --aq-mode 1 -o test2.h265 --preset slow
Sample (http://www.file-upload.net/download-8363232/test2.h265.html), log (http://pastebin.com/EadP16si)

1. I can't mux it using either l-smash or mp4box. Both suspect corruption.
2. It came out at only ~11 Mbytes for 2684 frames with horrible quality. I know I can decrease --crf further but is this really the quality expected for crf 18?
3. The log says "yuv [info]: 1920x800 24000Hz[...]". Should I have used "23.976" instead of "24000/1001"?

[Kurtnoise]

1. I can't mux it using either l-smash or mp4box. Both suspect corruption.
With mp4box : you have to use either the hevc/hvc/265 file extension or add :FMT=HEVC to your command line

So, either
mp4box -add input.hevc output.mp4

or
mp4box -add input.h265:FMT=HEVC output.mp4

[sneaker_ger]

Thx, that does indeed fix 1.

[fumoffu]

2. It came out at only ~11 Mbytes for 2684 frames with horrible quality. I know I can decrease --crf further but is this really the quality expected for crf 18?
3. The log says "yuv [info]: 1920x800 24000Hz[...]". Should I have used "23.976" instead of "24000/1001"?

I'm pretty sure those 2 are related, if x265 thinks the video is meant to be played at 24000fps ;-) it compresses the motion much, much, much more than usually so everything looks like crap if you play this at only 23.976...

[sneaker_ger]

I will test but it sounds reasonable. Totally blind to not notice 24000 != 24.000. Now when using "--fps 23.976" the log says "23Hz". Wondering if it just clips the log or if the output might be wrong (if there a timings in the raw stream at all).

[Kurosu]

--max-merge - what are we merging? I'm guessing partitions but I would love to know more how and when this works.
Partitions marked as merge will copy a neighbour partition motion as is (including one scaled from collocated block in another frame). The different potential motions are index in a specific order. Basically, this is a mean to declare an area that has the same motion.

--early-skip - what are we skipping?
Probably a fast termination of the best partitioning/search if the best encoded mode for the CU is skip (akin to merged 2Nx2N partition without residual)

--fast-cbf - what does cbf stands for again?
Coded block flag - whether there was residual in a transform block. I guess this is a fast decision, ie no need to test smaller transform sizes if there are already a lot of not-coded transform blocks.

[Sagittaire]

Well I test actualy this 0.6 build and optimistation (speed and quality) are simply terrific in few month. H264 is simply surpassed and by far. I test codec since 2003 and I use always the same trailer for that. x265 produce same output quality for psnr than H264 mainconcept codec at half bitrate. x265 is actualy not able to produce the same quality output for psnr than x264 10 bit in placebo mode at half bitrate. Anyway it's only the 0.6 version for x265 ... :eek:

In all my test with this trailer x264 10 bit in placebo mode is never able to produce the same quality output than MPEG4 ASP (XviD or DivX) at half bitrate. H265 is certainely the most advanced evolution (in codec generation comparison) that I have never see for new codec (and I test some codec since more 10 years) ... :eek:

[James Freeman]

x265 is actualy not able to produce the same quality output for psnr than x264 10 bit in placeb mode.

Can you please re-say that?
Do you mean x264 is still better than x265, at higher qualities?

[easyfab]

x265 is actualy not able to produce the same quality output for psnr than x264 10 bit in placeb mode.

At the same bitrate or half bitrate ?

[Sagittaire]

At the same bitrate or half bitrate ?
half bitrate ... I make correction ...

[fumoffu]

@Kurosu - thanks for explanations!

I will test but it sounds reasonable. Totally blind to not notice 24000 != 24.000. Now when using "--fps 23.976" the log says "23Hz". Wondering if it just clips the log or if the output might be wrong (if there a timings in the raw stream at all).

AFAIK there are no timings in raw stream, and the fps count is only used to tweak compression. With this in mind those decimal places aren't even important as there isn't that much of a difference. Few days ago I accidentally used 29.97fps to encode 23.976 clip and after muxing to mkv (with correct fps value) I couldn't even tell that it was encoded with faster fps.

[easyfab]

I also notice that even if a frame looks worse encoded by x265 than x264 (when comparing frame by frame ), when playing the video is much more pleasant for x265 encoded videos.
There must be some temporal filter or some noise processing in HEVC and not for AVC ?

[Sagittaire]

Can you please re-say that?
Do you mean x264 is still better than x265, at higher qualities?

No. x265 produce in my test quality between H264 Mainconcept (slowest mode) and x264 10 bits (placebo mode) at half bitrate. I have simply never see this difference bettwen previous and next generation codec ... :D

[James Freeman]

No. x265 produce in my test quality between H264 Mainconcept (slowest mode) and x264 10 bits (placebo mode) at half bitrate. I have simply never see this difference bettwen previous and next generation codec ... :D

That's great. :cool:

Can't wait till this implemented commercially world wide, especially for the new Blu-Ray standard.

[sneaker_ger]

AFAIK there are no timings in raw stream, and the fps count is only used to tweak compression. With this in mind those decimal places aren't even important as there isn't that much of a difference. Few days ago I accidentally used 29.97fps to encode 23.976 clip and after muxing to mkv (with correct fps value) I couldn't even tell that it was encoded with faster fps.
H.264 had timings and frame rate mode in the stream which could break some players or specs if not set exactly correct, that's why I'm asking.

I did test with --fps 23.976 now and bitrate was raised by ~60% at the same crf though it looked worse than the crf 18 I was used to from x264. For fun I made an x264 10 Bit encode with 2pass and preset veryslow at the same bitrate and the x265 one looked more pleasing. Artifacts were a lot less pronounced/visible, though it may have come out blurrier overall so the result might be different for decent bitrates or pre-filtering. Looking forward to the further development.

[Beelzebubu]

I also notice that even if a frame looks worse encoded by x265 than x264 (when comparing frame by frame ), when playing the video is much more pleasant for x265 encoded videos.
There must be some temporal filter or some noise processing in HEVC and not for AVC ?

This is likely because of the bigger block sizes. What sometimes happens with older codecs (e.g. h264) is that neighbouring blocks with virtually identical motion will get slightly different motion vectors (1 qpel value different, for example), because the RD doesn't take block edge artifacts into account. In new codecs (e.g. hevc), it will choose a bigger block size, which therefore gets a uniform motion vector, and thus the artifacts at block edges disappear.

[Procrastinating]

Because of the more accurate motion prediction of h265, I wonder if pseudo-slowmo won't look as awful now.