x265 HEVC Encoder

[x265_Project]

We've made a number of substantial improvements to x265 in the past few weeks. x265 documentation can be found here... http://x265.readthedocs.org/en/default/

Tom
MulticoreWare

[spookybathtub]

What is the maximum resolution supported by x265?

[professor_desty_nova]

It seems there a typo on the latest evaluators guide...
The new option "rd" appears as "-rd" on changes and suggested settings, and as "--rd" on "Standalone Executable Options" later on the same guide.

PS: only --rd works on x265.exe.

[filler56789]

Has anybody ever tested the following statement?

If not building in Windows XP but want the binary to be XP-compatible, enable WINXP_SUPPORT Cmake option.

Because so far, I still haven't seen any MSVS build of x265 compiled on a non-XP machine that can actually run under Windows XP.
Either you get the error message

The procedure entry point InterlockedCompareExchange64 could not be located in the dynamic link library KERNEL32.dll.

or you get the error message

"Path-To\x265.exe" is not a valid Win32 application.

[Kurtnoise]

Try this build (http://www.mediafire.com/?b634gqycw2bn82b)...

[filler56789]

Try this build (http://www.mediafire.com/?b634gqycw2bn82b)...

:thanks: It works ( finally, \o/ )

[ndkamal]

Will it have avisynth input ?

Like x264 encoder.

[filler56789]

Will it have avisynth input ?

Like x264 encoder.

Only indirectly, I'm afraid,
"stdin for video input in CLI app" is on their TODO list
( but that's a start, at least :) )

https://bitbucket.org/multicoreware/x265/wiki/TODO

[x265_Project]

It seems there a typo on the latest evaluators guide...
The new option "rd" appears as "-rd" on changes and suggested settings, and as "--rd" on "Standalone Executable Options" later on the same guide.

PS: only --rd works on x265.exe.

Thanks. Microsoft Word was auto-correcting double hyphens (--) to a single dash (–), driving me crazy until I found the setting that prevents this. We've posted a corrected version of the guide. x265_Evaluators_Guide_09-24-13.pdf (https://bitbucket.org/multicoreware/x265/downloads/x265_Evaluators_Guide_09-24-13.pdf)

We welcome participation in the project in every way, including help with better documentation (explanations of settings, etc.) and with any feedback on usage, etc. This has been challenging up to this point as x265 has been a moving target, undergoing fairly substantial fundamental changes over the past 6 months. We should be evolving to the point where we are doing more performance optimization of the existing algorithms, rather than replacing / implementing them, and to where we are able to focus on additional features and platforms.

We continue to experiment to find the most optimal settings for different situations, and we expect to have x264 style presets at some point (slow, faster, fastest, etc.). But we also welcome feedback in this area.

Thanks
Tom

[x265_Project]

More details on the state of x265 from our lead developer (Steve Borho)...

I've made a tag on the stable branch for 0.4.1. This email describes the state of the encoder at that tag.

x265 can be compiled and run on Linux, Mac OS X, and Windows. Its cmake based build system supports MSVC 9-11, Xcode, gcc+gmake, MinGW/MSYS, and Intel C++ (both icl and icpc)

x265 currently generates HM11 compliant bitstreams.

= New features since 0.3 =

1. Frame parallelism

* The GOP level parallelism and mini-gop cadence of the 0.3 release were removed and replaced with fine-grained frame level parallelism.
* The memory requirements were drastically reduced, x265 no longer caches subpel planes per reference frame
* Latency is drastically reduced, WPP + 5 frame threads is enough to saturate a dual socket 8 core Xeon.

2. New simple average bitrate (ABR) rate control

* converges on target bitrate via frame level QP adjustments
* algorithm was adapted from x264 for HEVC
* safe for use in combination with frame parallelsim (new since 0.4)

3. New Lookahead

* three complexity levels of slice decision with scene cut and flash detection
* algorithm was adapted from x264 for HEVC
* still missing bidir cost estimates, multiple refs, weightp, and MBtree


= Disabled Features since 0.3 =

* weightp and weighted bidir prediction are both disabled; they were broken when we stopped pre-generating reference (subpel) pixels
* GOP parallelism is dead, hopefully to never return to the core library. It could be added above x265 if necessary.
* many CLI options were added, removed, or renamed since 0.3. Consult the online help for the current set of options.


= Known Bugs =

* all intra encodes (--keyint 1) require --b-adapt 0 to avoid a lookahead bug
* --no-sao-lcu-bounds cannot be used in conjunction with frame parallelism. The encoder will use incomplete reference pixels with predictable bad effects.
* we have a report that our DPB signalling is potentially incorrect for decoders which respect max DPB size. This is under investigation.

ABR and lookahead are very new and we will not be surprised to find bugs in those features. Please report any bugs you find to this mailing list.


= Performance Characteristics =

See https://bitbucket.org/multicoreware/x265/wiki/Performance


= Upcoming features =

We are trying to make the encoder deterministic with -Fn for all values of n greater than 1. In other words, there will always be a slight benefit to having only one frame thread (unlimited motion search to reference frames) but -F2 and -F10 should output the exact same bitstream with CQP rate control. This is considered a debugging feature to validate our frame parallelism.

We are also planning to swap out the HM's bidir search with logic adapted from x264 (for performance reasons) and to add estimation logic for this new bidir search to the lookahead (to improve lookahead accuracy).

We plan to repair the weighted prediction features and re-enable its command line options.

Lastly, the lookahead will use wave-front scheduling of the lowres CUs using the existing thread pool. This should lesson the bottlenecking effects of --b-adapt 2.

[smok3]

Why not use a name that stands out a bit, like y265 ?
(Just a suggestion)

[lainiwaku]

is it hard to use command line version ? i always used MeGui for x264 :helpful:

[iwod]

Something less related. Is DS working on x265 yet?

[x265_Project]

is it hard to use command line version ? i always used MeGui for x264 :helpful:
I suppose it depends on your level of experience with command-line interfaces. If you've used a CLI before, you should find x265 fairly easy to use. CLIs have some advantages, including the ability to write batch files (scripts).

Keep in mind that x265 is really a core video encoding library, designed to be integrated into other software applications. Video editing and transcoding applications add more powerful capabilities like opening different types of media files, demultiplexing the content, decoding the source video into uncompressed frames, scaling video, frame rate conversion, transcoding audio, and packaging up the result in a file like .mp4 or .mkv.

Tom

[x265_Project]

Something less related. Is DS working on x265 yet?
I'll let DS speak for himself... but I would point you to the x265 development mailing list to see all of the activity from all of the different contributors. The project is ramping up nicely, and we're psyched to see so many talented people writing and reviewing code, submitting bugs and responding to open questions.

Tom

[Daemon404]

For anyone interested, I did a quick SSIM-based comparison of the 1-pass ABR modes in x264 and x265 (take it with a grain of salt). Source is Elephant's Dream, from here (http://media.xiph.org/video/derf/).

Pretty graph here (http://chromashift.org/img/x265/comparison_abr_27sep2013.png).

[LigH]

Doesn't tell me much more than "they are not completely different". But I feel that is a good conclusion. :)

[zerowalker]

Could someone put some Screen Comparisons of x265 and x264?

[LigH]

That won't make much sense without specific testing parameters. Even though x265 is nowhere near "feature complete", it is already able to encode in visually transparent quality with a certain bitrate or quality level. And it will, of course, have compression artefacts with a lack of.

In such an early testing stage, there are not even comparable default values. You will certainly not be able to make up "similar-quality options" for both encoders. The default quantization level in x265 (=32) is very coarse, limits the pixel-bitrate to values where compression artefacts are not only obvious but even annoying.

For a sensible comparison, one would have to find a quantization for x265 which gives a good result with still recognizable artefacts, and run x264 in 2-pass mode with the resulting bitrate as target; x265 does not even have a 2-pass mode, and 1-pass ABR is not optimal.

[zerowalker]

Ah, well if there isn´t a comparable setting, then it is indeed meaningless.

[Kurtnoise]

That won't make much sense without specific testing parameters.
Looking at the graph, you will see the parameters used : x264 -placebo + no-psy vs x265 defaults

[professor_desty_nova]

Maybe in a few weeks/months, when x265 has Weight P and Weight B working and more stuff borrowed from x264 (look at their TODO list (https://bitbucket.org/multicoreware/x265/wiki/TODO)), it will be more "fair" to compare...

[mandarinka]

I don't think those are specifically the problem. It's probably the rate control that is most important.

[LigH]

@ Kurtnoise:

I thought zerowalker asked for any comparison screenshots, not specifically from the test above. That's why I continued thinking about its general sense in the current stage of development...

Apart from other working features, there is also some need for useful default values. From my experience so far, a default quantizer of 32 in x265 is not really a sensible value.

[BadFrame]

Really love how development has picked up on the x265 project, I'm getting some good 'x264 vibes' :D

Is there a tool to decode the x265 generated raw hevc stream to another format at the moment?

[LigH]

The Osmo4 player in the GPAC Nightly Builds (Win32) can play it (muxed as MP4 with e.g. MP4Box in this package, or a current L-SMASH).

The HM reference decoder (ver. 12.0 currently?) can decode it to Y4M. JEEB's build (http://x264.fushizen.eu/builds/hevc-hm/hm_12.0_r3541_release.7z) (TAppDecoder.exe).

[BadFrame]

Thanks LigH!

[Kurtnoise]

Wanna play with avisynth & libx265 on windows platforms ?

I've made a fresh compile of avconv (http://www.mediafire.com/?z3dzrgag1y70ywi) from libav (http://git.khirnov.net/cgit.cgi/libav/log/?h=hevc_upstream) + patches (http://lists.libav.org/pipermail/libav-devel/2013-October/051599.html) from Daemon404...:cool:

Not all options from x265 cli are available yet but it's a good start.

[Kurtnoise]

Maybe...when hevc support in matroska (i.e in Mosu's mkvtoolnix, not Rovi) will be officially supported.

[nakTT]

is it hard to use command line version ? i always used MeGui for x264 :helpful:
Same here. I hope some GUI like MeGUI etc could integrate this encoder. I would love to do testing with this new encoder.

[Selur]

gui support in MeGui and other tools will probably not come unless input via std::in is supported.
Most GUIs won't support tools which require huge temporary files as input.

[LigH]

Apart from that, x265 is not yet available for users, only for testers with sound background knowledge in video coding algorithms, and working with CLI encoders (at least by editing a batch file) is the least issue in the current stage of development.

There is no complete feature implementation yet.
There is no stabe set of command line options yet.
How often do you expect a GUI to follow sudden and unexpected changes in the set of encoder options?

And yes: There is not even support for streaming video sources (pipe / AviSynth) yet. GUIs could not efficiently serve frames to such an encoder.

[nekrosoft13]

anyone could share a sample file encoded in x265?

[JEEB]

anyone could share a sample file encoded in x265?
Daemon404's test encodes are available in the directory (http://chromashift.org/img/x265/).

[filler56789]

anyone could share a sample file encoded in x265?

This thread @ Videohelp has various sample videos:

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds

[LigH]

Here are also a few of mine (http://www.mediafire.com/?6lfp2jlygogwa).

Also there are some new builds, compiled with MSys/MinGW GCC for x86 or with MSVC11 for x86 and AMD64 (latter may have a minimum requirement of Windows 7 and the MSVC 2012 Redistributable (http://www.microsoft.com/en-us/download/details.aspx?id=30679); a CPU with AVX support and 8 GB RAM are reommended): https://x265.cc/

[Kurtnoise]

Also there are some new builds, compiled with MSys/MinGW GCC for x86 or with MSVC11 for x86 and AMD64 (latter may have a minimum requirement of Windows 7 and the MSVC 2012 Redistributable (http://www.microsoft.com/en-us/download/details.aspx?id=30679); a CPU with AVX support and 8 GB RAM are reommended): https://x265.cc/
who has created this buildbot ? It's from official devs ?

For MSVC builds, it's quite easy to support XP platforms and remove the c++ runtime.

I'll create a patch if needed.

[LigH]

The user registered with the nick "x265.cc" in the VideoHelp forum (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2273873&viewfull=1#post2273873); I don't know if he is related to the development team.

[x265_Project]

The user registered with the nick "x265.cc" in the VideoHelp forum (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2273873&viewfull=1#post2273873); I don't know if he is related to the development team.

He is not.

Tom
MulticoreWare

[Kurtnoise]

Here is the patch:

# HG changeset patch
# User Kurtnoise <kurtnoise@free.fr>
# Date 1381898006 -7200
# Wed Oct 16 06:33:26 2013 +0200
# Node ID 723e554191e14e6289342043225e485e656c27d7
# Parent a998daed845922b3b880b48c0cafa32c422c941e
Add Windows XP support in MSVC11 builds. This requires CMake 2.8.11 or later.

diff -r a998daed8459 -r 723e554191e1 build/vc11-x86/make-solutions.bat
--- a/build/vc11-x86/make-solutions.bat Tue Oct 15 20:57:47 2013 -0500
+++ b/build/vc11-x86/make-solutions.bat Wed Oct 16 06:33:26 2013 +0200
@@ -3,4 +3,4 @@
:: run this batch file to create a Visual Studion solution file for this project.
:: See the cmake documentation for other generator targets
::
-cmake -G "Visual Studio 11" ..\..\source && cmake-gui ..\..\source
+cmake -G "Visual Studio 11" -T "v110_xp" ..\..\source && cmake-gui ..\..\source
diff -r a998daed8459 -r 723e554191e1 build/vc11-x86_64/make-solutions.bat
--- a/build/vc11-x86_64/make-solutions.bat Tue Oct 15 20:57:47 2013 -0500
+++ b/build/vc11-x86_64/make-solutions.bat Wed Oct 16 06:33:26 2013 +0200
@@ -3,4 +3,4 @@
:: run this batch file to create a Visual Studion solution file for this project.
:: See the cmake documentation for other generator targets
::
-cmake -G "Visual Studio 11 Win64" ..\..\source && cmake-gui ..\..\source
+cmake -G "Visual Studio 11 Win64" -T "v110_xp" ..\..\source && cmake-gui ..\..\source
diff -r a998daed8459 -r 723e554191e1 source/CMakeLists.txt
--- a/source/CMakeLists.txt Tue Oct 15 20:57:47 2013 -0500
+++ b/source/CMakeLists.txt Wed Oct 16 06:33:26 2013 +0200
@@ -7,7 +7,7 @@
endif()

project (x265)
-cmake_minimum_required (VERSION 2.8.8) # OBJECT libraries require 2.8.8
+cmake_minimum_required (VERSION 2.8.11) # OBJECT libraries require 2.8.11

# X265_BUILD must be incremented each time the public API is changed
set(X265_BUILD 1)


XP platforms require v110_xp as toolset instead of v110. Otherwise, applications don't run correctly on this platform.

This patch requires CMake 2.8.11 because the flag dedicated to the toolset has been fixed in this version.

[filler56789]

Hmmm, according to this post (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2274423&viewfull=1#post2274423), the patch suggested above "cannot be automated" or something.
:confused:

[Kurtnoise]

yes, I saw that in the mailing list...I think that can be retrieved by reading the reg value.

btw,

Not really matters if you build the makefiles without the batch files. Simply add the "-T "v110_xp"" switch to cmake.
Anyway nice work for batch users.
this guy doesn't understand what my patch does...the switch goes to the cmake command line.

[Kurtnoise]

And yes: There is not even support for streaming video sources (pipe / AviSynth) yet. GUIs could not efficiently serve frames to such an encoder.
Piping is under way (https://mailman.videolan.org/pipermail/x265-devel/2013-October/001766.html) now... :)



Edit: test build (http://www.mediafire.com/?r6v6rewf66ecl9d) uploaded.

[filler56789]

Piping is under way (https://mailman.videolan.org/pipermail/x265-devel/2013-October/001766.html) now... :)



Edit: test build (http://www.mediafire.com/?r6v6rewf66ecl9d) uploaded.

Thanks for the experimental build, but you didn't say whether it works or doesn't work on your machine(s) :)

I took the time to compile the latest commit with GCC 4.8.1, including the stdin patch, and sadly the best the EXE does is encode 0 frames :mad: when fed through avs2yuv.

[Monarc]

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?

[nevcairiel]

x265 is dual-licensed, like x264. Its available for free under GPL, but also available under a commercial license if your requirements are not compatible with the GPL. The text only states that the commercial license is not available until the product reaches a certain level of maturity.

[x265.cc]

this guy doesn't understand what my patch does...the switch goes to the cmake command line.

Can you please tell me what i haven't understood? It would be helpful for me. Thanks :)

btw. i've now implemented this (the commandline way) for my buildbot.

[Kurtnoise]

Thanks for the experimental build, but you didn't say whether it works or doesn't work on your machine(s) :)

I took the time to compile the latest commit with GCC 4.8.1, including the stdin patch, and sadly the best the EXE does is encode 0 frames :mad: when fed through avs2yuv.
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.

[Kurtnoise]

Can you please tell me what i haven't understood? It would be helpful for me. Thanks :)

btw. i've now implemented this (the commandline way) for my buildbot.
the batch file calls the patched cmake command line...what can I say moreover ?

[x265.cc]

the batch file calls the patched cmake command line...what can I say moreover ?

The use of

cmake -G "Visual Studio 11" -T "v110_xp" ..\..\source

only will not work.

Also the batch file cannot be automated due to the fact that it needs "cmake-gui".

Anyway, the automation of cmake (means commandline only) is really not a big deal.