x265 HEVC Encoder

[x265_Project]

One question about x265.

on x265.org i can read:


x265 is a commercially funded open source implementation


on x265.com:


As the x265 reaches production, flat fee and per-unit commercial licenses will be available for companies that cannot accept x265 under a GPL license.


So x265 is a normal commercial product?
And x265 will be re-licensed under a new licence, when ready?
And sold like a normal product?

Commercial licenses are available now for companies that wish to distribute x265 in their products without being subject to the conditions of the GPL license. Contact me - license at x265.com.

Tom
MulticoreWare

[MoSal]

Fact is, it does not work, at least on windows plateforms...Checking the code, it seems that the issue comes from guessFrameCount() function within the pipeline (i.e the seeking returns always 0). So, encoding cannot start and fails.

You can't seek in pipes. That has nothing to do with the platform.

Input should be buffered instead.
Obviously, piping is useless if you need to buffer the whole input.

[qyot27]

Concerning 16bpp, I'm wondering whether this is for the future implementation of higher bit depth output, to avoid the issues that have been noted regarding x264 and 12/14-bit support? Is it [mostly] irrelevant for current 8bpp-only encoding cases, or is there a generalized visual or coding efficiency benefit (I assume there might be) from having internal processing in 16bpp even though from what I can tell, the input and output of 16bpp builds is still restricted to only 8bpp? I'm assuming that there is some kind of performance hit from using 16bpp builds, just because of the higher complexity math and any discrepancies that might exist in the asm between the two versions.

I guess what I'm getting at here is, is the -DHIGH_BIT_DEPTH option actually worth using at this point in time? I've not seen this particular part explained.

[Kurtnoise]

You can't seek in pipes. That has nothing to do with the platform.

Input should be buffered instead.
Obviously, piping is useless if you need to buffer the whole input.
Well...I meant, guessFrameCount() uses the seekg/tellg to find the current position/size of the stream. That's all.

[DarrellS]

Finally, there are a couple of x265 builds that accept stdin "-".

http://forum.videohelp.com/attachments/208...ccac3a7d3622.7z


https://x265.cc/

Here is the working command argument for Virtualdub 1.10.3 external encoder...

--input-res %(width)x%(height) --fps %(fps) --q 24 --keyint 40 --max-merge 3 --hash 1 --no-rect --wpp --tu-intra-depth 1 --tu-inter-depth 1 --no-tskip --frame-threads 4 - -o "%(tempvideofile)"

[LigH]

A source patch for reading YUV4MPEG from stdin was published in the mailinglist. So expect a build with Y4M piping support soon™... ;)

[Kurtnoise]

It was already there in my package from here (http://forum.doom9.org/showthread.php?t=169607)...;)

[x265_Project]

New stable version tag 0.5

= New Features =
* x265 can now be built by Mac OS X clang compiler
* install/uninstall build targets (install-only for Windows)
* Our cmake scripts now build static and shared libraries
* --ref N is now supported for enabling multiple L0 references
* SSIM global statistic reporting (--ssim)
* CSV logging is now a core feature, introduced per-frame logging

= API Changes =
* "_t" suffix removed from public data types for POSIX compatibility
* public API is now versioned
* --cpuid meaning has changed from level to capability bitmap, same as x264
* param.bipredSearchRange has been removed (--bpredrange N)
* param.maxNumReferences has been added (--ref N)
* param.csvfn has been added (--csv FILENAME.csv)
* PSNR and/or SSIM reporting are optional (--[no-]psnr --[no-]ssim)
* x265_version_str exported string symbol with version (tag) info
* x265_build_info_str exported string symbol with compile info
* x265_encoder_get_stats() method for querying encoder statistics
* x265_encoder_log() method for writing to CSV log file
* x265_param_parse() method for configuring x265_param_t via strings
* x265 now requires cmake 2.8.8 or later in order to build
* Weightp options re-enabled, but feature is still unfinished
* param.rc.aqmode, param.rc.aqstrength for unfinished AQ support

= Improvements =
* x265 is deterministic at -F1 and separately deterministic for Fn>1
(ie: -F2 and -F12 will give the same outputs if all other args are same)
* We have adopted a bidir search more closely resembling x264's bidir
* Lookahead analysis now includes bidir candidates for B slice types
* Lookahead uses thread pool and wave-front block scheduling
* The "multiple of min CU size (4)" resolution requirement has been removed
* More x264 assembly is being used for motion search and bidir MC
* PSNR and SSIM are measured row-by-row after deblocking and SAO
* Use of Standard Template Library classes has been removed
* SIMD Vector Classes are no longer used for 8bpp primitives

= Upcoming improvements =
* support in CLI for reading YUV or Y4M on stdin (already in default)
* performance presets
* Main10 profile
* Weightp in lookahead, weight analysis adapted from x264
* lookahead worker thread
* Adaptive QP

[Kurtnoise]

Nice work...

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. ;)

[LigH]

The buildbot author reported that the compiling fails for the 16bpp branch. He may publish the logs there too...

[nevcairiel]

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]

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.

[x265_Project]

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]

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]

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 (http://forum.doom9.org/showthread.php?p=1650040#post1650040) 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]

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]

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 (http://www.imagemagick.org/script/binary-releases.php#windows) uses 'bits per pixel' to mean the 'bits per channel/component' case, so I just went with their description.

[qyot27]

@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).

[x265_Project]

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/index.php/powervr-video/the-emergence-of-hevc-and-10-bit-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]

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/index.php/powervr-video/the-emergence-of-hevc-and-10-bit-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-Xd3P6pWQI9NllMa2tGRUIwb0E/edit?usp=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]

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-Xd3P6pWQI9NllMa2tGRUIwb0E/edit?usp=sharing&pli=1
Check this one :
http://forum.doom9.org/showthread.php?p=1651083#post1651083

[James Freeman]

Compile? Encode, probably.
Yes, Encode.

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

It's the Bitrate of the original video.
Nothing to do with 802.11g.

The goal here is to test how much CPU it takes to decode a High Bitrate 1080p HEVC video, that is all.
108Mbps is higher than a typical Blu Ray with 30Mbps.
If you have anything higher than 108Mbps it will be of help.

I feel Hollywood will be more concentrated on higher bitrate with 1080p resolution, than UHD with lower bitrate.

For example:
The new 100GB discs with 1080p, but with HEVC, Higher Bitrate, Wider Gamut (Rec.2020), 4:2:2/4:4:4 Chroma, and HFR (maybe).
The quality will be comparable to Digital Cinema (2K) finally.

Lets call it Blu Ray 2 shall we. :eek: :cool:


Check this one :
http://forum.doom9.org/showthread.php?p=1651083#post1651083

Yeah, I already tested this one.

I got 21fps with: 3770K (4.5Ghz), GTX660 (nothing to do with it).

I specifically ask for the 1080p one for the reason I pointed above.

[LigH]

Well, I try to understand your point, but again ... it doesn't make much sense to try to reach the bitrate of an already lossy compressed "original" with another lossy compression algorithm. The encoder will mainly try to re-encode the quantization artefacts of the former copy, so you may spend a lot of time, but the result won't tell you much more than the time wasted.

I prefer to use (almost) lossless sources for testing, like Sintel (http://media.xiph.org/sintel/) (a Blender render movie which is available in different image dimensions – e.g. 1080p or 4K – and even high color resolution, 16 bpc = 48 bpp) as original, so I can even get a meaningful quality measure; just their downloads can take several days, due to the size of several Gigabytes.

For shorter tests, there is also the Sintel trailer in 1080p@24fps (Y4M (http://media.xiph.org/video/derf/y4m/sintel_trailer_2k_1080p24.y4m), 3.7 GB / PNG.tgz (http://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz), 900 MB).

[sneaker_ger]

He just wants to measure the decoding performance, artifacts and source quality don't matter for that.

[mandarinka]

Yes, but the resulting file might still not be representative. There could for example be more skips blocks and as a result, the decoding load would be lower than with a video coded from a lossless source.

[pieter3d]

Note that Main10 profile allows chroma and luma to have separate bits per pixel values, between 8..10 inclusive. So you can have either or both luma/chroma using bitdepths of 9.

[nevcairiel]

Note that Main10 profile allows chroma and luma to have separate bits per pixel values, between 8..10 inclusive. So you can have either or both luma/chroma using bitdepths of 9.

While this feature also existed in H.264, it was not really used by anything and not supported by most of the decoders. I would wager that this will remain the same situation with HEVC.

[pieter3d]

I disagree. While probably it won't be used often, it is part of Main 10 profile, so anyone wishing to build a compliant decoder must support it. I can promise you that all Main10 HW decoders will support it, as part of conformance. Encoders however, probably not unless there is a good special application.

[nevcairiel]

The same thing applies to H.264, yet many decoders didn't handle it, even if they otherwise handled 10-bit decoding - it was just never implemented, because it was never used.

[James Freeman]

Can anyone point me to a link with a 1080p HEVC 30Mbps+ NON-animated (reality) video sample?
I want to compare it with a typical blu ray quality (1080p H.264 30Mbps+).

I want to compare CPU-Load & Picture Quality.

Thanks.

[iSunrise]

...I feel Hollywood will be more concentrated on higher bitrate with 1080p resolution, than UHD with lower bitrate...
That´s not how marketing works.

[James Freeman]

That´s not how marketing works.

I can understand that.
4K is alot shinier than HD

What do you think the future of Blu Ray will look like?

[Guest]

What do you think the future of Blu Ray will look like? Not on-topic for this thread. Please open a new one.

[mandarinka]

The same thing applies to H.264, yet many decoders didn't handle it, even if they otherwise handled 10-bit decoding - it was just never implemented, because it was never used.

Well, there were no decoders for High 10 to begin with. There is only CoreAVC and libavcodec and both are software. Also, they probably don't care much about being completely conformant to the whole spec.

[LigH]

Can anyone point me to a link with a 1080p HEVC 30Mbps+ NON-animated (reality) video sample?

The closest lossless source to "reality" I have is "Tears of Steel". I'm just testing an encode of an action cut of one minute, the result may be available today or tomorrow, depending on the speed and resulting bitrate. And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...

[James Freeman]

@LigH

Thank you for the upcoming test video.
A minute of footage will be enough to compare HEVC vs H.264.

And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...

I have no idea what padding is.
Do you mean HEVC is too efficient so the results are always less than 30Mbps?
If that's the case, its Great!


I thought of a good comparison method.
Visual (SSIM) & File Size:

File Size comparison (same visual quality):
1. x264 encoded to 30Mbps with a resulting X SSIM value.
2. Set HEVC with the same X SSIM value but let it compress to what Bitrate as it wants.

This test is good to compare how much will we able to put into a single defined space, like an optical disc.
For example: How many hours of film will we be able to put into the same size with the same quality.

Visual Comparison (same file size):
1. x264 encoded to 30Mbps with a resulting X SSIM value.
2. HEVC encoded to 30Mbps with a different resulting Y SSIM.

This test is good to visually compare how much better the picture quality will be in the same file size.

[zerowalker]

I am a bit confused as i haven´t been following H265.

Which encoder is the one i should look at, is it this x265?

And if so, which of them, i see the one linked at first post, and i know the one at Google Source thing?
Or are they the same?

Also, how is it looking, is it still a child to be fed, or is it starting to look like something so to speak?

Thanks

[filler56789]

I have no idea what padding is.

When you set the encoder to achieve a target bitrate "X", and the resulting stream has an actual bitrate "less than X", then the encoder may fill the video stream with NULL bytes.

And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...

Correct :) Still, you could try the following settings:

--- disable B-frames

--- use short GOPs (i.e., more I-frames)

--- use low quantizers (18 or even less)

HTH :)

[LigH]

Well, yes, it is possible to get quite high bitrates locally. Limiting the encoding efficiency will reduce the required decoding efforts as well, though, therefore I'm trying to create a rather complex video with longer GOPs, severe referencing, and still high bitrates; so the only way to achieve that is a low quantization. CRF 12 appears to be promising... more later.

To keep the bitrate in a closer range, x265 would require a VBV like regulation, though.

And yes, stuffing would mean to fill up the video with non-bitstream junk just to keep the brutto bitrate rather constant; the only known use (to me) for this waste would be DVB bouquets, and maybe optical disk material to avoid buffer overflows.

[Kurtnoise]

Does anybody confirm that the latest x265 builds (with the latest commits from today) are broken using the pipeline ?

I tested my own builds and the ones from x265.cc, all fail...at least with yuv.

[LigH]

Version 0.5+153 (VC12 x86-64) works in general with Y4M file input, but produces artefacts with a complex command line:

-F 3 -q 23 -b 3 --b-adapt 2 --bframe-bias 30 -w --ref 3 -i 240 --psnr --ssim --rdpenalty 1 --aq-mode 1

Same for piping Y4M via avs2yuv: Works in general, but produces artefacts.

Same for piping raw YUV i420 via avs2yuv: Works in general, but produces artefacts.
__

Hmm. Different command line option set, no artefacts...

--preset slower --crf 24 -F 6 -w --bframe-bias 30 -i 240 --rdpenalty 1 --aq-mode 1