x265 HEVC Encoder

[pingfr]

You forgot ULTRA and TURBO words.

I actually did not forget those... I was saving them up for the next milestone! :devil:

x265-2.1-reloaded-extended-unleashed-extreme-edition-super-combo-deluxe-ultra-turbo-titanium-edition+1 :devil:

[pingfr]

@x265_Project: Hey Tom.

In my case it's a single x265.exe running at once, no parallel encoding (yet), so in this case Xeon E5-2687W v3 (10C/20T@3.1GHz/3.5GHz) would "win" the encoding race versus a Xeon E5-2697 v3 (14C/28T@2.6GHz/3.6GHz) because the turbo feature actually "flattens" (don't know the technical term) each core to the stock base frequency when all cores are properly equally saturated.

So ideally it's a matter of comparing 10 cores back to 3.1GHz for the E5-2687W v3 against 14 cores back to 2.6GHz for the Xeon E5-2697 v3... hopefully I got it right.

Summarized: it's more efficient to have 10 cores running at 500MHz faster than having more (in this case, 4 extras) 14 cores running at slower speeds? (pardon the poor wording).

Speaking of the "devil"... is there any official pricing for UHDkit licensing available to the public/general audience?

[Stacey Spears]

What is the process to request a feature for x265? e.g. I have all of the UHD BD constraints and would like to know how to get them on the todo list for x265. Assuming there is interest. I would like to use it to encode my next disc. I used x264 on the current test/calibration disc.

[x265_Project]

What is the process to request a feature for x265? e.g. I have all of the UHD BD constraints and would like to know how to get them on the todo list for x265. Assuming there is interest. I would like to use it to encode my next disc. I used x264 on the current test/calibration disc.
Hi Stacey,
The official way to request a new feature is through our Bitbucket Issues tracker (https://bitbucket.org/multicoreware/x265/issues?status=new&status=open). UHD-BD compatibility is something we've been working on. One of our developers submitted a patch, and it should soon be supported in the development builds. I'll check on it for you.

[Stacey Spears]

Thank you for the quick response. Would be happy to test the patch with some of the BD authoring tools if I could get a build. Would also like to make sure the developer has all of the data needed. I have it all in a PDF. I can PM you the PDF.

After I submitted my feature request, I noticed someone else already requested it. (maxqp) So I added additional comments to the existing request and you can close my new one if you like.

[Ely]

Any idea what encoder is used by professionals when authoring current UDH BD ?

[LigH]

There is already a number of HEVC products (https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding_implementations_and_products). Among the more famous vendors are: Ericsson, Vanguard, Fraunhofer HHI, MainConcept, Ateme (who cooperated with DivX Networks already), NHK (Japan Broadcasting Corp.) + Mitsubishi Electrics ... Ittiam Systems from India is not so famous to me, but they are developing an own HEVC encoder already for longer. And don't we forget GPU vendors like Nvidia.

So it seems that there is already a quite generous range to choose from. I guess the MainConcept SDK is probably among the best selling software solutions. Hardware encoders (usually focused on realtime encoding with lower complexity) are probably sold by general and mobile-affine electronic companies.

[Stacey Spears]

Any idea what encoder is used by professionals when authoring current UDH BD ?

Several UHD BD titles have been authored using Ateme. Biggest issue right now is that it does not offer segment re-encoding.

[2themax]

Several UHD BD titles have been authored using Ateme. Biggest issue right now is that it does not offer segment re-encoding.
Sirius Pixels can't get their encoder to market fast enough to solve that problem.

[pingfr]

Hey guys.

I'm facing a small dilemma here, which would be faster for x265 (no parallel encoding), between these 2 architectures:

2*E5 26XX v3 8C/16T@2.9GHz (35M cache L3) vs 2*E5 26XX v3 12C/24T@2.8GHz (30M cache L3).

If anyone with moderate x86-64 architecture knowledge could shed some light, it would be greatly appreciated, thanks.

[Atak_Snajpera]

8C vs 12C??? Choice is obvious.

[littlepox]

8C*2 vs 12C*2
No parallel encoding
Then it is not obvious anymore.
The answer, as far as I have tested, heavily depends on the source and your settings.
Without further infomation I'd suggest 12C since the frequence lead for 8C is so small.

[Atak_Snajpera]

12C@2.8Ghz will always be faster than 8C@2.9GHz. Period. Ofcourse speed-up will be much less than 1.5x.

[LigH]

x265 1.9+96-b09998b1256e (https://www.mediafire.com/download/npaaaw9gdfaoeln/x265_1.9+96-b09998b1256e.7z) should have fixed the bitrate control for zones.

[pingfr]

@Atak_Snajpera & @littlepox: Thanks for the heads up guys, I shall follow your advices and cancel my pending order of 2* 8C@2.9GHz and head for the 2* 12C@2.8GHz route. :)

[x265_Project]

Hey guys.

I'm facing a small dilemma here, which would be faster for x265 (no parallel encoding), between these 2 architectures:

2*E5 26XX v3 8C/16T@2.9GHz (35M cache L3) vs 2*E5 26XX v3 12C/24T@2.8GHz (30M cache L3).

If anyone with moderate x86-64 architecture knowledge could shed some light, it would be greatly appreciated, thanks.
Agreed... the extra cores will be a bigger benefit than 100 MHz of clock and 5 MB of cache.

[pingfr]

Agreed... the extra cores will be a bigger benefit than 100 MHz of clock and 5 MB of cache.

Thanks a bunch! much.. err.. "love". :)

[benwaggoner]

Agreed... the extra cores will be a bigger benefit than 100 MHz of clock and 5 MB of cache.
IF the output frame size is large enough. A 640x272 might not see any benefit.

[pingfr]

@benwaggoner: Mostly encoding 1920x1040, 1920x868, 1920x808, 1920x800 then a couple of a 1280x560 and 1280x532 cropped material IIRC.

[Grojm]

Any news on this issue? https://bitbucket.org/multicoreware/x265/issues/214/ghosting-artefacts-even-with-low-crf-when
This is a tremendous bug leading to a huge impact on video quality. It has been reported months ago. But little attention by the developers.

[LigH]

I just checked the small samples ({u}hd177.y4m) from the BitBucket issue tracker with x265 v1.9+96 (all presets incl. "-D 10 --crf 15" as documented); indeed, there are choppy/flickering/inconsistent motions for small objects. Preset "slower" appears to produce the most obvious issues. I tested with several parameters which should change the behaviour of mini-GOPs (B-frame bias; B-frame pyramid; weighted P/B frames); the effect did not disappear.

For some reason, I don't see any "Reply" button in the BitBucket issue tracker, despite being logged in; is there a user/project permission required? Or maybe it's just incompatible with Opera 12, or I'm missing a JavaScript import via proxy. It works in Pale Moon.

[littlepox]

I just checked the small samples ({u}hd177.y4m) from the BitBucket issue tracker with x265 v1.9+96 (all presets incl. "-D 10 --crf 15" as documented); indeed, there are choppy/flickering/inconsistent motions for small objects. Preset "slower" appears to produce the most obvious issues. I tested with several parameters which should change the behaviour of mini-GOPs (B-frame bias; B-frame pyramid; weighted P/B frames); the effect did not disappear.



try --qcomp 0.8 --psy-rd 0.3

[LigH]

@ littlepox:

Nope, always flickering still. Archived result. (http://www.ligh.de/tmp/uhd177_slower.7z)

[pingfr]

@ littlepox:

Nope, always flickering still. Archived result. (http://www.ligh.de/tmp/uhd177_slower.7z)

For what it's worth, can't see much either... I mean 384x160 all pixellated garbage... could use some 576p material at least. :p

[Ma]

Could someone tell me where in source code is function for choose object/shape that will be moved?

[Grojm]

For what it's worth, can't see much either... I mean 384x160 all pixellated garbage... could use some 576p material at least. :p

Try the original Star Wars example, attached in comment #4 on bitbucket. It's 720p and the effect is notable at normal resolutions.

[LigH]

I'll try this, but because I have no AVX capable CPU, it will take a longer while to test that...

[pingfr]

I'll try this, but because I have no AVX capable CPU, it will take a longer while to test that...

Hey LigH,

Any ideas of "how longer" are we talking about here for a CPU without AVX and AVX 2.0 instruction sets compared to a CPU with said instructions?

In terms of either time spent/percentages/fps, any rough guesses will do.

Just out of curiosity.

[LigH]

I don't know, because I can't compare. If you have a CPU which supports better instructions, you can disable their use. But not vice-versa.

With an AMD Phenom-II, the maximum supported instruction set is "SSE2-Fast". Not even SSE3 or SSSE4.

[pingfr]

Hey guys,

Having a few issues to get x265 to compile on Windows systems here.

- SourceTree is installed & I cloned the repo succesfully.
- YASM 1.30 is installed as well and is in the path (in fact I just copy'ed over in %windir%).
- GCC is installed (gcc version 5.3.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project).
- CMake 3.5.0 is installed as well (and cmake-gui as well).

I have succesfully cloned the repo but in the build subfolder I only see arm-linux, linux, msys, vc9 vc10 vc11 vc12 and xcode sub-subdirs.

Excuse me if I'm a bit "clueless" here, but I don't see a gcc subdir and can't locate a CMakeLists.txt to use with cmake-gui tool either.

If anyone could enlight me...

[LigH]

To compile for Windows, you would probably prefer to set up an MSYS/MinGW environment, as described in the VideoHelp forum (http://forum.videohelp.com/forums/11-Video-Conversion) posts about this topic ([HEVC] x265.EXE: mingw builds (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds) | x265 HEVC Encoder (http://forum.videohelp.com/threads/360069-x265-HEVC-Encoder)). You can easily download a whole prepared MSYS environment from XhmikosR (http://xhmikosr.1f0.de/tools/msys/); use a link to the included msys.bat with the parameter "-mintty" to call MinTTY as shell, it is a lot more user friendly than sh and also supports LOCALE (e.g. a translation for accent chars and umlauts). Then you can call the shell scripts inside the ~/x265/build/msys directory (~ is your home directory where you are logged in when calling the MSYS shell), after cloning x265 from the BitBucket repo there using hg.

Another approach is using jb-alvarado's media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite), set up to only build x265 (or in addition to ffmpeg, as you like).

[pingfr]

Moi@X99 ~/x265/x265/build/msys
$ cmake -G "MSYS Makefiles" ../../source && cmake-gui ../../source
-- cmake version 3.5.0
-- The C compiler identification is GNU 5.3.0
-- The CXX compiler identification is GNU 5.3.0
-- Check for working C compiler: C:/MSYS/mingw/bin/gcc.exe
-- Check for working C compiler: C:/MSYS/mingw/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/MSYS/mingw/bin/g++.exe
-- Check for working CXX compiler: C:/MSYS/mingw/bin/g++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detected x86 target processor
-- Looking for include file inttypes.h
-- Looking for include file inttypes.h - found
-- Performing Test CC_HAS_NO_STRICT_OVERFLOW
-- Performing Test CC_HAS_NO_STRICT_OVERFLOW - Success
-- Performing Test CC_HAS_NO_NARROWING
-- Performing Test CC_HAS_NO_NARROWING - Success
-- Performing Test CC_HAS_NO_ARRAY_BOUNDS
-- Performing Test CC_HAS_NO_ARRAY_BOUNDS - Success
-- Performing Test CC_HAS_FAST_MATH
-- Performing Test CC_HAS_FAST_MATH - Success
-- Performing Test CC_HAS_STACK_REALIGN
-- Performing Test CC_HAS_STACK_REALIGN - Success
-- Performing Test CC_HAS_FNO_EXCEPTIONS_FLAG
-- Performing Test CC_HAS_FNO_EXCEPTIONS_FLAG - Success
-- Found yasm: C:/MSYS/bin/yasm.exe (found version "1.3.0")
-- Found Yasm 1.3.0 to build assembly primitives
-- hg found at C:/Program Files/TortoiseHg/hg.exe
-- x265 version 1.9+100-ed744166c37e
-- The ASM_YASM compiler identification is unknown
-- Found assembler: C:/MSYS/bin/yasm.exe
-- Looking for strtok_r
-- Looking for strtok_r - found
-- Looking for include file getopt.h
-- Looking for include file getopt.h - found
CMake Error at CMakeLists.txt:621 (LIST):
list sub-command REMOVE_DUPLICATES requires list to be present.


CMake Warning (dev) at CMakeLists.txt:622 (set):
Cannot set "PLATFORM_LIBS": current scope has no parent.
This warning is for project developers. Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!
See also "C:/MSYS/home/Moi/x265/x265/build/msys/CMakeFiles/CMakeOutput.log".
See also "C:/MSYS/home/Moi/x265/x265/build/msys/CMakeFiles/CMakeError.log".

Moi@X99 ~/

[LigH]

This forum's bbCode subset offers a CODE tag to present such pre-formatted results in a monospaced font.
__

It looks not bad yet, up to the point that there may be a bug in the preparation of the CMake directives. I'll try to confirm that.
__

OK, I have that warning about PLATFORM_LIBS too, but not about REMOVE_DUPLICATES (still using CMake 3.4.1).

[pingfr]

Don't bother, I've switched to media-autobuild_suite, it's still updating lots of missing packages but seems to be fine so far.

[LigH]

Sometimes you just get an unfortunate moment with a buggy source state. Next week it may already be fixed.

[qyot27]

The REMOVE_DUPLICATES error also shows up for me when cross-compiling under Lubuntu 16.04 Beta 1, which has CMake 3.3.2 or 3.2.2* (I can't make heads nor tails of that back-asswards version string (http://packages.ubuntu.com/xenial/cmake)...pick just one, guys). It's safe to just comment that one line out and carry on, as a band-aid before it gets fixed upstream. It seems like it's only there to eliminate duplicate copies of dependent libs from all getting linked in, or something.

*although I'm also pretty sure it's also CMake 3.5.0, since I remember seeing '3.5' or something similar when configuring the project.

[LigH]

I'm confident x265_Project will read here soon. I believe to remember that another fix in this area was already proposed (only use PLATFORM_LIBS where useful)...

[nandaku2]

I'm confident x265_Project will read here soon. I believe to remember that another fix in this area was already proposed (only use PLATFORM_LIBS where useful)...

Sorry, folks. PLATFORM_LIBS fix patch pushed.

[LigH]

Experimental UHD Bluray support (--uhd-bd) in x265 1.9+106-c8ec86965e54 (https://www.mediafire.com/download/b11kgzti9w4gglu/x265_1.9+106-c8ec86965e54.7z); is there anyone who can test and confirm?

[sneaker_ger]

BluRay patch:
if ((p->sourceWidth != 1920 && p->sourceWidth != 3840) || (p->sourceHeight != 1080 && p->sourceHeight != 1088 && p->sourceHeight != 2160))
1957
+ {
1958
+ x265_log(p, X265_LOG_ERROR, "uhd-bd: Supported resolutions are 1920x1080, 1920x1088 and 3840x2160\n");
1959
+ disableUhdBd = 1;
1960
+ }
1920x1088 is only allowed with conformance window cropping to 1920x1080 (like on regular BluRay using H.264). Since x265 does not allow to manually set conformance window cropping this should not be allowed. (but 1920x1080 input with --min-cu-size 16 should be possible)

[sneaker_ger]

/edit:
ok, hrd is working. I didn't turn vbv on and it wasn't checked by --uhd-bd.
1. But with vbv without --level there is an actual error: general_level_idc is set to 0 which isn't valid at all. Log shows strange error:
x265 [info]: Main 10 profile, Level-1.9+106-c8ec86965e54 (Main tier)
The problem does not occur if you manually specify --level 5.1.

2. x265 tries no lowers vbv from 100000 to 40000, even though the log says it is using high tier. This can be worked around again by manually specifying --high-tier.

(There's more)

[x265_Project]

BluRay patch:
if ((p->sourceWidth != 1920 && p->sourceWidth != 3840) || (p->sourceHeight != 1080 && p->sourceHeight != 1088 && p->sourceHeight != 2160))
1957
+ {
1958
+ x265_log(p, X265_LOG_ERROR, "uhd-bd: Supported resolutions are 1920x1080, 1920x1088 and 3840x2160\n");
1959
+ disableUhdBd = 1;
1960
+ }
1920x1088 is only allowed with conformance window cropping to 1920x1080 (like on regular BluRay using H.264). Since x265 does not allow to manually set conformance window cropping this should not be allowed. (but 1920x1080 input with --min-cu-size 16 should be possible)
Thanks. Do you want to sign a Contributor License Agreement (https://bitbucket.org/multicoreware/x265/downloads/x265ContributorAgreement.pdf) and submit this patch?

[sneaker_ger]

You misunderstood. It's not my patch, it is a quote from your code.

[x265_Project]

You misunderstood. It's not my patch, it is a quote from your code.
Oh... sorry. I see what you're saying in the original message. We'll take a look at this.

[J1Man]

Hi Guys. I am trying to encode 16bit Yuv 4:2:0 source material into 10bit hevc using x265 10bit build. Should I convert 16bit input into 10bit (via third party tools) before I send it to x265? Or is it better to let x265 handle 16bit to 10bit conversion?

I did some visual comparisons but I could not decide which method is the best, quality wise.

Thanks.

[littlepox]

Hi Guys. I am trying to encode 16bit Yuv 4:2:0 source material into 10bit hevc using x265 10bit build. Should I convert 16bit input into 10bit (via third party tools) before I send it to x265? Or is it better to let x265 handle 16bit to 10bit conversion?

I did some visual comparisons but I could not decide which method is the best, quality wise.

Thanks.

I don't think there is any significant difference. For me, I'd just use --dither --input-depth 16 and that's fine.

[jlpsvk]

hi all, what would be better in terms of speed of encoding (at same settings) - i7-3930K (6C/12T with 4x4GB RAM Quad-Channel) or i7-4790K (4C/8T with 2x8GB RAM Dual-Channel)? Thanks for suggestion. I have both, but want to keep one for work, and one for encoding with x265.

[sneaker_ger]

Zond (free demo available here (http://www.dektec.com/products/applications/Zond/)) reports errors when using HRD:
Frame num Offset Source Description
0 0x00000459 Conformance to HEVC specification SEI: When an SEI NAL unit containing an active parameter sets SEI message is present in an access unit, it shall be the first SEI NAL unit that follows the prevVclNalUnitInAu of the SEI NAL unit and precedes the nextVclNalUnitInAu of the SEI NAL unit (Section D.3.1)
0 0x00000462 Conformance to HEVC specification SEI: When a non-nested buffering period SEI message is present in an access unit, it shall not follow any other SEI message that follows the prevVclNalUnitInAu of the buffering period SEI message and precedes the nextVclNalUnitInAu of the buffering period SEI message, other than an active parameter sets SEI message (Section D.3.1)
0 0x00000472 Conformance to HEVC specification SEI: When a non-nested picture timing SEI message is present in an access unit, it shall not follow any other SEI message that follows the prevVclNalUnitInAu of the picture timing SEI message and precedes the nextVclNalUnitInAu of the picture timing SEI message, other than an active parameter sets SEI message or a non-nested buffering period SEI message (Section D.3.1)
Example command:
x265 "input" -o "output" --level 5.1 --high-tier --vbv-maxrate 100000 --vbv-bufsize 100000 --hrd

[sneaker_ger]

Specific sample can trigger more errors:
Summary
Errors count 12
Different errors count 5
Frames count with errors 3
Frame num Offset Source Description
0 0x00000466 Conformance to HEVC specification SEI: When an SEI NAL unit containing an active parameter sets SEI message is present in an access unit, it shall be the first SEI NAL unit that follows the prevVclNalUnitInAu of the SEI NAL unit and precedes the nextVclNalUnitInAu of the SEI NAL unit (Section D.3.1)
0 0x0000046f Conformance to HEVC specification SEI: When a non-nested buffering period SEI message is present in an access unit, it shall not follow any other SEI message that follows the prevVclNalUnitInAu of the buffering period SEI message and precedes the nextVclNalUnitInAu of the buffering period SEI message, other than an active parameter sets SEI message (Section D.3.1)
0 0x0000047e Conformance to HEVC specification SEI: When a non-nested picture timing SEI message is present in an access unit, it shall not follow any other SEI message that follows the prevVclNalUnitInAu of the picture timing SEI message and precedes the nextVclNalUnitInAu of the picture timing SEI message, other than an active parameter sets SEI message or a non-nested buffering period SEI message (Section D.3.1)
2 0x00000bd5 Conformance to HEVC specification SEI: When an SEI NAL unit containing an active parameter sets SEI message is present in an access unit, it shall be the first SEI NAL unit that follows the prevVclNalUnitInAu of the SEI NAL unit and precedes the nextVclNalUnitInAu of the SEI NAL unit (Section D.3.1)
2 0x00000bde Conformance to HEVC specification SEI: When a non-nested buffering period SEI message is present in an access unit, it shall not follow any other SEI message that follows the prevVclNalUnitInAu of the buffering period SEI message and precedes the nextVclNalUnitInAu of the buffering period SEI message, other than an active parameter sets SEI message (Section D.3.1)
2 0x00000bed Conformance to HEVC specification SEI: When a non-nested picture timing SEI message is present in an access unit, it shall not follow any other SEI message that follows the prevVclNalUnitInAu of the picture timing SEI message and precedes the nextVclNalUnitInAu of the picture timing SEI message, other than an active parameter sets SEI message or a non-nested buffering period SEI message (Section D.3.1)
2 0x00000bd5 Conformance to HEVC specification SEI: An SEI NAL unit containing an active parameter sets SEI message shall contain only one active parameter sets SEI message (Section D.3.1)
25 0x0000ea1c Conformance to HEVC specification SEI: When an SEI NAL unit containing an active parameter sets SEI message is present in an access unit, it shall be the first SEI NAL unit that follows the prevVclNalUnitInAu of the SEI NAL unit and precedes the nextVclNalUnitInAu of the SEI NAL unit (Section D.3.1)
25 0x0000ea25 Conformance to HEVC specification SEI: The value of nal_initial_cpb_removal_delay[0] shall be less than or equal to 90000 * ( CpbSize[0] / BitRate[ 0 ] ), the time-equivalent of the CPB size in 90 kHz clock units. But it is equal to 90001, CpbSize[ 0 ] is equal to 100000000, BitRate [ 0 ] is equal to 100000000 (section D.3.2)
25 0x0000ea25 Conformance to HEVC specification SEI: When a non-nested buffering period SEI message is present in an access unit, it shall not follow any other SEI message that follows the prevVclNalUnitInAu of the buffering period SEI message and precedes the nextVclNalUnitInAu of the buffering period SEI message, other than an active parameter sets SEI message (Section D.3.1)
25 0x0000ea34 Conformance to HEVC specification SEI: When a non-nested picture timing SEI message is present in an access unit, it shall not follow any other SEI message that follows the prevVclNalUnitInAu of the picture timing SEI message and precedes the nextVclNalUnitInAu of the picture timing SEI message, other than an active parameter sets SEI message or a non-nested buffering period SEI message (Section D.3.1)
25 0x0000ea1c Conformance to HEVC specification SEI: An SEI NAL unit containing an active parameter sets SEI message shall contain only one active parameter sets SEI message (Section D.3.1)
x265_main10.exe source.y4m --uhd-bd --level 5.1 --high-tier --vbv-maxrate 100000 --vbv-bufsize 100000 --colorprim 1 --colormatrix 1 --transfer 1 -o uhd-bd_test.265
Package with input and output file plus log: download (http://217.160.126.132/x265_uhdbd_hrd_errors.7z)

[Boulder]

I don't think there is any significant difference. For me, I'd just use --dither --input-depth 16 and that's fine.Some time ago, I tried using --dither when the output was 10bit. The encoder didn't complain but the output was garbage.

Then I checked the docs and it says:
Only applicable when the input bit depth is larger than 8bits and internal bit depth is 8bits.

Maybe there should be a sanity check?