MulticoreWare Annouces x265/HEVC Mission Statement
(Tuesday, July 23, 2013 at 9:06:23 PM BST)
The goal of x265 is to become the best open source H.265/HEVC encoder,with the highest compression efficiency at the highest performance,while also allowing commercial use via a dual GPL and commercial license. In a nutshell, we would like to reproduce x264's successful development model for HEVC.
Initial development has been commercially funded in order to get the project boot-strapped and generally useful in much shorter time than it normally takes for an open sourced video encoder.
This means both identifying open source developers who are already working on HEVC codecs in their spare time and paying them to work on it full time, as well as funding a team of optimization experts (MulticoreWare) to build a codec framework that will scale well to many-core PCs and servers, graphics processors, and mobile devices.
The x265 project is being funded by commercial companies who are investing in the start up cost in return for a commercial license and the ability to direct the development requirements. Commercial licensees receive the same software as the general public, but they are able to integrate x265 into their products without having to release their entire product as GPL. See commercial [license]. Commercial licensees are required to contribute back all changes that they make to x265 source files (including changes to files with BSD license headers). They are also responsible for separately acquiring licenses for any HEVC related patents.
The x265 project has licensed the rights to utilize and modify x264 source code in x265. While x265 will not be directly based on x264 source code, our intent is to borrow heavily from x264 those features that apply to HEVC. For instance adaptive quantization, lookahead, and rate control strategies.
x265 aims to support both Visual Studio and GCC as dual first-class compiler targets. Since Intel's compilers can mimic those two compilers, it will also be supported on Windows and Linux. All SIMD and assembly language optimizations will work with both compilers. x265 will be written in C++, and CMake will be used to generate Makefiles and solution files. We will write vector/intrinsic versions of all assembly optimized core routines, to both ease porting to new platforms and to ease developer adoption. We want x265 to be the first encoder a student chooses to work on.
In order to have a functioning encoder as soon as possible, we have decided to base x265 on the JCT-VC HM reference encoder and to simultaneously remove cruft as we optimize and improve the performance. Over time, we expect all of the HM source files to be replaced with more streamlined (and unambiguously GPL) sources. The HM serves as a helpful scaffold to build from.
Footnote on GPL and BSD Licenses The HM source code is BSD licensed, whereas our x265 project is licensed under the GNU GPL 2. The BSD license allows users to use/modify the code in any manner, so long as the the BSD license is left in place. The GPL requires you to contribute back any changes that you make. GPL projects may use BSD-licensed files, but not vice versa. We are aiming to replace all BSD licensed source files (derived from HM) with GPL licensed sources. All source files in this project are being distributed under the terms of the GPL 2 license.
+ Reply to Thread
Results 1 to 5 of 5
[ d e l e t e d ]
Last edited by El Heggunte; 23rd Jul 2013 at 21:25.
that's a hell of a mission statement, i'll make a prediction right now...they will fail to become the widely used h265 encoder they hope to be.
divx/rovi already has an sdk, a decoder, an mkv muxer and soon a hevc encoder and they are already working with their partners to bring divx hevc supporting players to market soon.
similarly, the Strongene encoder is already way better than x264 and is ready for licensing.
these guys hope is for them to bring a gpu powered version to market fast so that there encoder offers much faster performance than any competitors.
based on some of the decisions the head honcho has made, as well as the fact that Jason of x264 fame is loosely associated with this project, i don't think we'll be seeing a gpu powered version of x265 any time soon.
// TODO: figure out what this is doing, replace with something more accurate // what is setColFromL0Flag() for? ........... // TODO: figure out what this is all about, replace with something more accurate ...................... // TODO: Remove dQP? .......... /* TODO: remove? */
reminds me of the linux kernel, years ago i used to custom compile kernels for the redhat and suse distros i would tri-boot with windows and for the custom knoppix remasters i was working on, anyway i would peruse through the code every once in a while and i remember one comment in a section of the linux kernel that delt with memory allocation and it said "does this belong here?".
i was like "wow!".