x265 HEVC Encoder

[nevcairiel]

Originally Posted by Kurtnoise

btw, what is the status of high bits depth ? It looks like it's clamped to 8bits in the current code...but I'm just wondering.

Main10 profile is listed in the "Upcoming improvements" section...

[Kurtnoise]

Ups, yeah, I missed that...thanks.

[BadFrame]

Originally Posted by x265_Project

x265 reaches 0.5 milestone

New stable version tag 0.5:

That's some very impressive progress, seems x265 is on a the same excellent path as x264 before it, great work!

[professor_desty_nova]

It seems that with the new --preset switch, the default values are not the ones shown in --h (help) anymore.

Before the presets, they are the same:

G:\x265_0.5+72-e842b2a4aeeb>x265 --frames 1 G:\x264\TestClipsYUV\ducks_take_off_420_720p50.y4m -o test.hevc
y4m  [info]: 1280x720 50Hz, frames 0 - 0 of 500
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast LZCNT
x265 [info]: performance primitives: intrinsic assembly
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: WPP streams / pool / frames  : 12 / 4 / 1
x265 [info]: CU size                      : 64
x265 [info]: Max RQT depth inter / intra  : 3 / 3
x265 [info]: ME / range / subpel / merge  : star / 60 / 5 / 5
x265 [info]: Keyframe min / max           : 250 / 250
x265 [info]: Rate Control                 : CQP-32
x265 [info]: Lookahead / bframes / badapt : 10 / 3 / 1
x265 [info]: tools: rect amp rd=2 ref=1 lft sao-lcu sign-hide tskip(fast+rdo)
x265 [info]: frame I:1      kb/s: 36872.80 PSNR Mean: Y:36.404 U:36.833 V:39.259

x265 [info]: global:        kb/s: 36872.80 PSNR Mean: Y:36.404 U:36.833 V:39.259

encoded 1 frames in 4.71s (0.21 fps), 36872.80 kb/s, Global PSNR: 36.814

After presets commit, not anymore:

G:\x265_0.5+90-f81af999ef6c>x265 --frames 1 G:\x264\TestClipsYUV\ducks_take_off_420_720p50.y4m -o test.hevc
y4m  [info]: 1280x720 50Hz, frames 0 - 0 of 500
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast LZCNT
x265 [info]: performance primitives: intrinsic assembly
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: WPP streams / pool / frames  : 12 / 4 / 1
x265 [info]: CU size                      : 64
x265 [info]: Max RQT depth inter / intra  : 1 / 1
x265 [info]: ME / range / subpel / merge  : star / 60 / 5 / 3
x265 [info]: Keyframe min / max           : 250 / 250
x265 [info]: Rate Control                 : CQP-32
x265 [info]: Lookahead / bframes / badapt : 10 / 3 / 1
x265 [info]: tools: rect amp rd=0 ref=1 lft sao-lcu sign-hide
x265 [info]: frame I:1      kb/s: 38479.60 PSNR Mean: Y:36.366 U:36.744 V:39.278

x265 [info]: global:        kb/s: 38479.60 PSNR Mean: Y:36.366 U:36.744 V:39.278

encoded 1 frames in 2.53s (0.40 fps), 38479.60 kb/s, Global PSNR: 36.778

PS: It seems to me that "--preset medium" is used by default, and overrides the (older?) default values that appear in --h (help).

[Selur]

anyone manged to compile x265 on Mac OS X?
Tried it myself, but I'm really not good with using a mac.

I checked out the source using SourceTree, opened a terminal, called the x265/build/linux/make-Makefiles.bash (there I set x86_64 as architecture, called configure and generate), then I called make and got:

 1%] Building CXX object encoder/CMakeFiles/encoder.dir/__/Lib/TLibEncoder/NALwrite.cpp
/Users/selur/x265/source/Lib/TLibEncoder/NALwrite.cpp:1: error: -mstackrealign not supported in the 64bit mode
make[2]: *** [encoder/CMakeFiles/encoder.dir/__/Lib/TLibEncoder/NALwrite.cpp] Error 1
make[1]: *** [encoder/CMakeFiles/encoder.dir/all] Error 2
make: *** [all] Error 2

so I removed -mstackrealign from x265\source\CMakeLists.txt and ran make-Makefiles.bash again (configure and generate), now calling make I ended up with:

[  1%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComBitStream.cpp.o
[  2%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComDataCU.cpp.o
[  4%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComLoopFilter.cpp.o
[  5%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComMotionInfo.cpp.o
[  7%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPattern.cpp.o
[  8%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPic.cpp.o
[ 10%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPicSym.cpp.o
[ 11%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPicYuv.cpp.o
[ 12%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPicYuvMD5.cpp.o
[ 14%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPrediction.cpp.o
[ 15%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComRom.cpp.o
[ 17%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComSampleAdaptiveOffset.cpp.o
[ 18%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComSlice.cpp.o
[ 20%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComTrQuant.cpp.o
[ 21%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComWeightPrediction.cpp.o
[ 22%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComYuv.cpp.o
[ 24%] Building CXX object common/CMakeFiles/common.dir/x86/asm-primitives.cpp.o
[ 25%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/pixel-a.asm.o
[ 27%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/const-a.asm.o
[ 28%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/cpu-a.asm.o
[ 30%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/sad-a.asm.o
[ 31%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/mc-a.asm.o
[ 32%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/mc-a2.asm.o
[ 34%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/ipfilter8.asm.o
[ 35%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/pixel-util.asm.o
[ 37%] Building CXX object common/CMakeFiles/common.dir/vec/vec-primitives.cpp.o
/Users/selur/x265/source/common/vec/vec-primitives.cpp:121: warning: unused parameter ‘p’
/Users/selur/x265/source/common/vec/vec-primitives.cpp:121: warning: unused parameter ‘cpuMask’
[ 38%] Building CXX object common/CMakeFiles/common.dir/primitives.cpp.o
[ 40%] Building CXX object common/CMakeFiles/common.dir/pixel.cpp.o
[ 41%] Building CXX object common/CMakeFiles/common.dir/dct.cpp.o
[ 42%] Building CXX object common/CMakeFiles/common.dir/ipfilter.cpp.o
[ 44%] Building CXX object common/CMakeFiles/common.dir/intrapred.cpp.o
[ 45%] Building CXX object common/CMakeFiles/common.dir/cpu.cpp.o
cc1plus: error: unrecognized command line option "-Wno-narrowing"
make[2]: *** [common/CMakeFiles/common.dir/cpu.cpp.o] Error 1
make[1]: *** [common/CMakeFiles/common.dir/all] Error 2
make: *** [all] Error 2

Cu Selur

[MoSal]

cc1plus: error: unrecognized command line option "-Wno-narrowing"

Are you building with clang?
Maybe "-Wnarrowing" is GCC-specific.

Originally Posted by professor_desty_nova

It seems that with the new --preset switch, the default values are not the ones shown in --h (help) anymore.
...
PS: It seems to me that "--preset medium" is used by default, and overrides the (older?) default values that appear in --h (help).

Yes, we have started to implement x264 style presets. As part of this work the values for the "medium" performance preset have become the new default values. I apologize that our documentation efforts haven't kept pace with our development efforts. We'll get a new Evaluator's Guide posted ASAP.

The presets are as follows (default values are used wherever a setting is not specified).

ultrafast=-s 32 --b-adapt 0 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=0 --max-merge=1 --me=0 --no-amp --no-rect --no-tskip --early-skip --fast-cbf --no-lft --no-sao --no-signhide --no-weightp
superfast=-s 32 --b-adapt 0 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=1 --max-merge=1 --me=1 --no-amp --no-rect --no-tskip --early-skip --fast-cbf --no-signhide --no-weightp
veryfast=--b-adapt 0 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=1 --me=1 --max-merge=2 --no-amp --no-rect --no-tskip --early-skip --fast-cbf
faster=--b-adapt 0 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=1 --me=1 --max-merge=2 --no-amp --no-rect --no-tskip --early-skip
fast=--tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=1 --me=1 --max-merge=2 --no-amp --no-rect --no-tskip
medium=--tu-inter-depth=1 --tu-intra-depth=1 --rd 2 --max-merge=3 --no-amp --no-rect --no-tskip
slow=--b-adapt 2 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 2 --max-merge=3 --no-tskip
slower=--b-adapt 2 --rc-lookahead 20 -b 5 --tu-inter-depth=2 --tu-intra-depth=2 --rd 2 --max-merge=4 --no-tskip --ref 3
veryslow=--b-adapt 2 --rc-lookahead 30 -b 9 --max-merge=5 --ref 5
placebo=--b-adapt 2 -b 16 --max-merge=5 --ref 16 --merange 124 --rc-lookahead 60

These are a fairly quick first take at the right settings to use for these presets. We're not satisfied that these are optimal at this point. For example, placebo mode should produce HM reference quality compression efficiency under any circumstance, and in our early tests it doesn't yet. As you select slower presets we want to see a clear improvement in compression efficiency (quality@ any bit rate), and as you select faster presets we want to see the minimum possible tradeoff in compression efficiency for the maximum improvement in encoding speed.

Keep in mind that for faster performance you will need to set the number of frames to be encoded in parallel (-F), and that you should also use --no-progress.

As this is an open source project, we welcome your testing of these presets and your suggestions for improvement. I'll monitor this thread for your feedback. We have our own tests underway also.

Tom
MulticoreWare

[qyot27]

Originally Posted by Selur

anyone manged to compile x265 on Mac OS X?
Tried it myself, but I'm really not good with using a mac.

I checked out the source using SourceTree, opened a terminal, called the x265/build/linux/make-Makefiles.bash (there I set x86_64 as architecture, called configure and generate), then I called make and got:

[snip]
Cu Selur

IMO, the build/ directory should just be ignored.

It builds just fine under OSX if you just use cmake directly.

hg clone https://bitbucket.org/multicoreware/x265
cd x265/source
cmake .
make
sudo make install

If you want a 16bpp build, then tack -DHIGH_BIT_DEPTH:bool=on onto the cmake command. If 16bpp fails to build, it doesn't necessarily mean the default 8bpp build has the same problem.

[sneaker_ger]

What does "16bpp" mean? I thought even 12 Bit encoding is still nothing but a draft?

[qyot27]

Originally Posted by sneaker_ger

What does "16bpp" mean? I thought even 12 Bit encoding is still nothing but a draft?

16 bits per pixel (or maybe plane).

The internal precision of the encoder doesn't necessarily have anything to do with the output depth. No one answered my previous question on the relevance of the 16bpp build so anything I'd say is pure conjecture.

[Selur]

@qyot27: did a clean checkout and 'cmake .' ends with:

Building CXX object encoder/CMakeFiles/encoder.dir/__/Lib/TLibEncoder/NALwrite.cpp
/Users/selur/x265/source/Lib/TLibEncoder/NALwrite.cpp:1: error: -mstackrealign not supported in the 64bit mode
make[2]: *** [encoder/CMakeFiles/encoder.dir/__/Lib/TLibEncoder/NALwrite.cpp] Error 1
make[1]: *** [encoder/CMakeFiles/encoder.dir/all] Error 2
make: *** [all] Error 2

(got a clean Snow Leopard install with Xcode 4 installed)

Are you building with clang?
Maybe "-Wnarrowing" is GCC-specific.

I guess, only installed Xcode 4 and it's command line tools,..

[poisondeathray]

Originally Posted by qyot27

16 bits per pixel (or maybe plane).

I don't know what terminology conventions HEVC uses, but traditionally BPP is different than BPC

BPC is bits per channel . e.g. 8bits R, 8bits B, 8bits G for "8bit RGB" , or 8bit Y, 8bit U, 8bit V for "8bit YUV". It's usually expressed as per channel as in each channel . 8bit values would allow for 2^8 or (0 to 255) = 256 values per channel . It's also referred to as "bit depth"

BPP is bits per pixel . It's usually expressed as the sum of the bits in all the channels . However, because of chroma subsampling , the amount of bits is reduced

YV12 4:2:0 is "12bpp" because U , V ,are reduced in dimension 1/2 for width and height . e.g. 1920x1080 is only 960x540 in each U, V plane or 1/4 of the bits. So 8 + 2 + 2 = 12

YUY2 4:2:2 is "16bpp" because U, V planes are 1/2 of the bits, or 8+4+4 = 16

[qyot27]

Originally Posted by poisondeathray

I don't know what terminology conventions HEVC uses, but traditionally BPP is different than BPC

BPC is bits per channel . e.g. 8bits R, 8bits B, 8bits G for "8bit RGB" , or 8bit Y, 8bit U, 8bit V for "8bit YUV". It's usually expressed as per channel as in each channel . 8bit values would allow for 2^8 or (0 to 255) = 256 values per channel . It's also referred to as "bit depth"

BPP is bits per pixel . It's usually expressed as the sum of the bits in all the channels . However, because of chroma subsampling , the amount of bits is reduced

YV12 4:2:0 is "12bpp" because U , V ,are reduced in dimension 1/2 for width and height . e.g. 1920x1080 is only 960x540 in each U, V plane or 1/4 of the bits. So 8 + 2 + 2 = 12

YUY2 4:2:2 is "16bpp" because U, V planes are 1/2 of the bits, or 8+4+4 = 16

Well, obviously there is some confusion on that. For what it's worth, ImageMagick uses 'bits per pixel' to mean the 'bits per channel/component' case, so I just went with their description.

[qyot27]

Originally Posted by Selur

@qyot27: did a clean checkout and 'cmake .' ends with:

(got a clean Snow Leopard install with Xcode 4 installed)


I guess, only installed Xcode 4 and it's command line tools,..

It would appear that the -mstackalign issue is a common problem for 64-bit Snow Leopard. At the very least, Homebrew requires Lion for the x265 formula:
https://github.com/mxcl/homebrew/commit/fe806e9adb03f7f3fe87b8b6153e864f19bfa1d8

And they make mention of the -mstackalign issue in the formula.

It *might* be possible to get around it for Snow Leopard if you build your compilation toolchain from scratch and make sure it's updated enough, but that's only a guess (and beyond what the average user is willing to do).

Originally Posted by poisondeathray

I don't know what terminology conventions HEVC uses, but traditionally BPP is different than BPC

BPC is bits per channel . e.g. 8bits R, 8bits B, 8bits G for "8bit RGB" , or 8bit Y, 8bit U, 8bit V for "8bit YUV". It's usually expressed as per channel as in each channel . 8bit values would allow for 2^8 or (0 to 255) = 256 values per channel . It's also referred to as "bit depth"

BPP is bits per pixel . It's usually expressed as the sum of the bits in all the channels . However, because of chroma subsampling , the amount of bits is reduced

YV12 4:2:0 is "12bpp" because U , V ,are reduced in dimension 1/2 for width and height . e.g. 1920x1080 is only 960x540 in each U, V plane or 1/4 of the bits. So 8 + 2 + 2 = 12

YUY2 4:2:2 is "16bpp" because U, V planes are 1/2 of the bits, or 8+4+4 = 16

In video coding, bits per pixel is generally understood to mean the # of bits per sample (per pixel per color), not the sum of all bits in all channels for each pixel. For example, note how Imagination uses a row labeled "bit/pixel" in their chart when defining their HEVC decoding capability - http://withimagination.imgtec.com/in...colour-formats. It is not as technically accurate as bits/color or bits/sample, but it is fairly prevalent, even among video professionals. It's understood by the context that we're not talking about 8, 10 or 12 bits for the whole RGB or YUV pixel.

Obviously, you can't use 8 bit internal precision when working with decoded video that was encoded with 10 or 12 bits per sample. So, the encoder must switch over to using 16 bit values internally (even though the least 6 or 4 significant bits will be zero). For obvious reasons, this will impact performance.

x265 can be built to use 8 bit internal precision, or (with the HIGH_BIT_DEPTH build option) 16 bit internal precision. The HIGH_BIT_DEPTH version of x265 has not been an area of focus in the initial months of the project, but are fully committed to supporting high bit depths, and we are starting to devote more time and attention to this now.

Tom
MulticoreWare

[mandarinka]

I don't know any details, but it seems that some sort of CRF rate-control has landed in x265 code tree: https://bitbucket.org/multicoreware/x265/commits/c51c35880df53def63953e95d81ad90b56ea67b9

[poisondeathray]

Originally Posted by x265_Project

In video coding, bits per pixel is generally understood to mean the # of bits per sample (per pixel per color), not the sum of all bits in all channels for each pixel. For example, note how Imagination uses a row labeled "bit/pixel" in their chart when defining their HEVC decoding capability - http://withimagination.imgtec.com/in...colour-formats. It is not as technically accurate as bits/color or bits/sample, but it is fairly prevalent, even among video professionals. It's understood by the context that we're not talking about 8, 10 or 12 bits for the whole RGB or YUV pixel.

Obviously, you can't use 8 bit internal precision when working with decoded video that was encoded with 10 or 12 bits per sample. So, the encoder must switch over to using 16 bit values internally (even though the least 6 or 4 significant bits will be zero). For obvious reasons, this will impact performance.

x265 can be built to use 8 bit internal precision, or (with the HIGH_BIT_DEPTH build option) 16 bit internal precision. The HIGH_BIT_DEPTH version of x265 has not been an area of focus in the initial months of the project, but are fully committed to supporting high bit depths, and we are starting to devote more time and attention to this now.

Tom
MulticoreWare

Thanks, It's good that you clarify that

There is some confusion, it almost feels like a "switcharoo" , sort of like how "PAR" or pixel aspect ratio was used in MPEG2 terminology but "SAR" or sample aspect ratio is used in MPEG4-AVC terminology

I'm not sure of the historical orgins, but I think the the term "bpp" was derived from old computer graphics displays . For example, Microsoft uses the old terminology for video rendering.

http://msdn.microsoft.com/en-us/library/windows/desktop/dd206750%28v=vs.85%29.aspx#YUV420formats12bitsperpixel

[James Freeman]

Can someone please compile this video with HEVC while retaining maximum bitrate.

"Ducks take off" 1080p 108Mbps MKV.
https://docs.google.com/file/d/0B-Xd...=sharing&pli=1

[LigH]

Compile? Encode, probably.

Recoding from a quite lossy source may not make much sense. A best possible source is always preferable. The file name (including "CRF25") suggests a rather low quality.

And furthermore, the rate control of x265 is probably not yet implemented up to the ability of ensuring a specific maximum bitrate, this would certainly require a VBV or similar implementation.

BTW, you ask for a maximum of 108 Mbps, this looks like a double 802.11g WLAN rate?

[Brazil2]

Originally Posted by James Freeman

Can someone please compile this video with HEVC while retaining maximum bitrate.
"Ducks take off" 1080p 108Mbps MKV.
https://docs.google.com/file/d/0B-Xd...=sharing&pli=1

Check this one :
http://forum.doom9.org/showthread.ph...83#post1651083