x265 HEVC Encoder

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.

Originally Posted by 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.

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

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

[Kurtnoise]

Try this build...

[filler56789]

Originally Posted by Kurtnoise

Try this build...

It works ( finally, \o/ )

[ndkamal]

Will it have avisynth input ?

Like x264 encoder.

[filler56789]

Originally Posted by ndkamal

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

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/...ki/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.