x265_2.1/.hg_archival.txt0000644000000000000000000000025212772433167015201 0ustar rootroot00000000000000repo: 09fe40627f03a0f9c3e6ac78b22ac93da23f9fdf node: 3e8ce3b26319dbd53ab6369e4c4e986bf30f1315 branch: stable latesttag: 2.1 latesttagdistance: 1 changessincelatesttag: 1 x265_2.1/.hgignore0000644000000000000000000000017212772433167013717 0ustar rootroot00000000000000syntax: glob doc/uncrustify/uncrustify.exe build/ **.rej **.orig **.hevc **.yuv **.y4m **.out **.swp .DS_Store x265_2.1/.hgtags0000644000000000000000000000174012772433167013374 0ustar rootroot0000000000000099fab2ef92be051cd3b3b2d817064cead282b42c 0.1 b3471d9009f5cd487b23c8c61a6bfff8980e54f2 0.2 3767fbfa970ff4b2dc2e8647db0274168727147e 0.3 2ba6ec553f218d2b06ad803b87d6ec751fd639f7 0.4 93707bc4fccdaa89a1f2da11db8808ca912a691c 0.4.1 69acb3cb777f977f5edde908069ac565915dd366 0.5 b970ffbdd696e3ce45c93b315902eb6366ff085e 0.6 d24e2a8c4326b0cd01bfa6c414c5378481af9018 0.7 527d03c56d6860dc979ddea1196f7e94d13d3e82 0.8 82bbd2bf3b49ba086be0f0922f91fe0084896351 0.9 cea97c4d79456842e00ade6be6fd5ec34610e5f8 1.0 ae9609aeebdc3271114168ece003679e9b1dca1b 1.1 d6257335c5370ee54317a0426a12c1f0724b18b9 1.2 c1e4fc0162c14fdb84f5c3bd404fb28cfe10a17f 1.3 5e604833c5aa605d0b6efbe5234492b5e7d8ac61 1.4 9f0324125f53a12f766f6ed6f98f16e2f42337f4 1.5 cbeb7d8a4880e4020c4545dd8e498432c3c6cad3 1.6 8425278def1edf0931dc33fc518e1950063e76b0 1.7 e27327f5da35c5feb660360336fdc94bd0afe719 1.8 1d3b6e448e01ec40b392ef78b7e55a86249fbe68 1.9 960c9991d0dcf46559c32e070418d3cbb7e8aa2f 2.0 981e3bfef16a997bce6f46ce1b15631a0e234747 2.1 x265_2.1/COPYING0000644000000000000000000004331012772433167013150 0ustar rootroot00000000000000 GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. , 1 April 1989 Ty Coon, President of Vice This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. This program is also available under a commercial proprietary license. For more information, contact us at license @ x265.com. x265_2.1/build/README.txt0000644000000000000000000000504112772433167014711 0ustar rootroot00000000000000= Mandatory Prerequisites = * GCC, MSVC (9, 10, 11, 12), Xcode or Intel C/C++ * CMake 2.8.8 or later http://www.cmake.org * On linux, ccmake is helpful, usually a package named cmake-curses-gui Note: MSVC12 requires cmake 2.8.11 or later = Optional Prerequisites = 1. Yasm 1.2.0 or later, to compile assembly primitives (performance) For Windows, download the latest yasm executable http://yasm.tortall.net/Download.html and copy the EXE into C:\Windows or somewhere else in your %PATH% that a 32-bit app (cmake) can find it. If it is not in the path, you must manually tell cmake where to find it. Note: you do not need the vsyasm packages, x265 does not use them. You only need the yasm executable itself. On Linux, the packaged yasm may be older than 1.2, in which case so you will need get the latest source and build it yourself. Once YASM is properly installed, run cmake to regenerate projects. If you do not see the below line in the cmake output, YASM is not in the PATH. -- Found Yasm 1.3.0 to build assembly primitives Now build the encoder and run x265 -V: x265 [info]: using cpu capabilities: MMX, SSE2, ... If cpu capabilities line says 'none!', then the encoder was built without yasm. 2. VisualLeakDetector (Windows Only) Download from https://vld.codeplex.com/releases and install. May need to re-login in order for it to be in your %PATH%. Cmake will find it and enable leak detection in debug builds without any additional work. If VisualLeakDetector is not installed, cmake will complain a bit, but it is completely harmless. = Build Instructions Linux = 1. Use cmake to generate Makefiles: cmake ../source 2. Build x265: make Or use our shell script which runs cmake then opens the curses GUI to configure build options 1. cd build/linux ; ./make-Makefiles.bash 2. make = Build Instructions Windows = We recommend you use one of the make-solutions.bat files in the appropriate build/ sub-folder for your preferred compiler. They will open the cmake-gui to configure build options, click configure until no more red options remain, then click generate and exit. There should now be an x265.sln file in the same folder, open this in Visual Studio and build it. = Version number considerations = Note that cmake will update X265_VERSION each time cmake runs, if you are building out of a Mercurial source repository. If you are building out of a release source package, the version will not change. If Mercurial is not found, the version will be "unknown". x265_2.1/build/arm-linux/crosscompile.cmake0000644000000000000000000000110312772433167020626 0ustar rootroot00000000000000# CMake toolchain file for cross compiling x265 for ARM arch # This feature is only supported as experimental. Use with caution. # Please report bugs on bitbucket # Run cmake with: cmake -DCMAKE_TOOLCHAIN_FILE=crosscompile.cmake -G "Unix Makefiles" ../../source && ccmake ../../source set(CROSS_COMPILE_ARM 1) set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR armv6l) # specify the cross compiler set(CMAKE_C_COMPILER arm-linux-gnueabi-gcc) set(CMAKE_CXX_COMPILER arm-linux-gnueabi-g++) # specify the target environment SET(CMAKE_FIND_ROOT_PATH /usr/arm-linux-gnueabi) x265_2.1/build/arm-linux/make-Makefiles.bash0000644000000000000000000000015712772433167020604 0ustar rootroot00000000000000#!/bin/bash # Run this from within a bash shell cmake -G "Unix Makefiles" ../../source && ccmake ../../source x265_2.1/build/linux/make-Makefiles.bash0000755000000000000000000000015612772433167020031 0ustar rootroot00000000000000#!/bin/bash # Run this from within a bash shell cmake -G "Unix Makefiles" ../../source && ccmake ../../source x265_2.1/build/linux/multilib.sh0000755000000000000000000000172612772433167016540 0ustar rootroot00000000000000#!/bin/sh mkdir -p 8bit 10bit 12bit cd 12bit cmake ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON make ${MAKEFLAGS} cd ../10bit cmake ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF make ${MAKEFLAGS} cd ../8bit ln -sf ../10bit/libx265.a libx265_main10.a ln -sf ../12bit/libx265.a libx265_main12.a cmake ../../../source -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON make ${MAKEFLAGS} # rename the 8bit library, then combine all three into libx265.a mv libx265.a libx265_main.a uname=`uname` if [ "$uname" = "Linux" ] then # On Linux, we use GNU ar to combine the static libraries together ar -M </dev/null fi x265_2.1/build/msys/make-Makefiles.sh0000644000000000000000000000016512772433167017357 0ustar rootroot00000000000000#!/bin/sh # Run this from within an MSYS bash shell cmake -G "MSYS Makefiles" ../../source && cmake-gui ../../source x265_2.1/build/msys/make-x86_64-w64-mingw32-Makefiles.sh0000644000000000000000000000054612772433167022220 0ustar rootroot00000000000000#!/bin/sh # This will generate a cross-compile environment, compiling an x86_64 # Win64 target from a 32bit MinGW32 host environment. If your MinGW # install is 64bit, you can use the native compiler batch file: # make-Makefiles.sh cmake -G "MSYS Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain-x86_64-w64-mingw32.cmake ../../source && cmake-gui ../../source x265_2.1/build/msys/multilib.sh0000755000000000000000000000145512772433167016373 0ustar rootroot00000000000000#!/bin/sh mkdir -p 8bit 10bit 12bit cd 12bit cmake -G "MSYS Makefiles" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON make ${MAKEFLAGS} cp libx265.a ../8bit/libx265_main12.a cd ../10bit cmake -G "MSYS Makefiles" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF make ${MAKEFLAGS} cp libx265.a ../8bit/libx265_main10.a cd ../8bit cmake -G "MSYS Makefiles" ../../../source -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON make ${MAKEFLAGS} # rename the 8bit library, then combine all three into libx265.a using GNU ar mv libx265.a libx265_main.a ar -M <' where is one of" @echo " html to make standalone HTML files" @echo " pickle to make pickle files" @echo " json to make JSON files" @echo " htmlhelp to make HTML files and a HTML help project" @echo " qthelp to make HTML files and a qthelp project" @echo " qhc to make QHC file" @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter" @echo " man to make manpages" @echo " changes to make an overview over all changed/added/deprecated items" @echo " linkcheck to check all external links for integrity" clean: -rm -rf build/* distclean: clean -rmdir build/ html: mkdir -p build/html build/doctrees $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) build/html @echo @echo "Build finished. The HTML pages are in build/html." zip: html (cd build ; zip TortoiseHg.html.zip -r html) pickle: mkdir -p build/pickle build/doctrees $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) build/pickle @echo @echo "Build finished; now you can process the pickle files." web: pickle json: mkdir -p build/json build/doctrees $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) build/json @echo @echo "Build finished; now you can process the JSON files." htmlhelp: mkdir -p build/htmlhelp build/doctrees $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) build/htmlhelp @echo @echo "Build finished; now you can run HTML Help Workshop with the" \ ".hhp project file in build/htmlhelp." qthelp: mkdir -p build/qthelp build/doctrees $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) build/qthelp @echo @echo "Build finished; now you can run "qcollectiongenerator" with the" \ ".qhcp project file in build/qthelp, like this:" @echo "# qcollectiongenerator build/qthelp/foo.qhcp" @echo "To view the help file:" @echo "# assistant -collectionFile build/qthelp/foo.qhc" qhc: qthelp $(QCOLLECTIONGENERATOR) build/qthelp/TortoiseHg.qhcp @echo "Build finished. To view the help file:" @echo "# assistant -collectionFile build/qthelp/TortoiseHg.qhc" latex: mkdir -p build/latex build/doctrees $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) build/latex @echo @echo "Build finished; the LaTeX files are in build/latex." @echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \ "run these through (pdf)latex." man: mkdir -p build/man build/doctrees $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) build/man @echo @echo "Build finished; the manpages are in build/man." @echo "Run \`man -l build/man/x265.1' or \`man -l build/man/libx265.3'" \ "to view them." changes: mkdir -p build/changes build/doctrees $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) build/changes @echo @echo "The overview file is in build/changes." linkcheck: mkdir -p build/linkcheck build/doctrees $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) build/linkcheck @echo @echo "Link check complete; look for any errors in the above output " \ "or in build/linkcheck/output.txt." x265_2.1/doc/reST/api.rst0000644000000000000000000005511512772433167015050 0ustar rootroot00000000000000********************************* Application Programming Interface ********************************* Introduction ============ x265 is written primarily in C++ and x86 assembly language but the public facing programming interface is C for the widest possible portability. This C interface is wholly defined within :file:`x265.h` in the source/ folder of our source tree. All of the functions and variables and enumerations meant to be used by the end-user are present in this header. Where possible, x265 has tried to keep its public API as close as possible to x264's public API. So those familiar with using x264 through its C interface will find x265 quite familiar. This file is meant to be read in-order; the narrative follows linearly through the various sections Build Considerations ==================== The choice of Main or Main10 profile encodes is made at compile time; the internal pixel depth influences a great deal of variable sizes and thus 8 and 10bit pixels are handled as different build options (primarily to maintain the performance of the 8bit builds). libx265 exports a variable **x265_max_bit_depth** which indicates how the library was compiled (it will contain a value of 8 or 10). Further, **x265_version_str** is a pointer to a string indicating the version of x265 which was compiled, and **x265_build_info_str** is a pointer to a string identifying the compiler and build options. .. Note:: **x265_version_str** is only updated when **cmake** runs. If you are making binaries for others to use, it is recommended to run **cmake** prior to **make** in your build scripts. x265 will accept input pixels of any depth between 8 and 16 bits regardless of the depth of its internal pixels (8 or 10). It will shift and mask input pixels as required to reach the internal depth. If downshifting is being performed using our CLI application (to 8 bits), the :option:`--dither` option may be enabled to reduce banding. This feature is not available through the C interface. Encoder ======= The primary object in x265 is the encoder object, and this is represented in the public API as an opaque typedef **x265_encoder**. Pointers of this type are passed to most encoder functions. A single encoder generates a single output bitstream from a sequence of raw input pictures. Thus if you need multiple output bitstreams you must allocate multiple encoders. You may pass the same input pictures to multiple encoders, the encode function does not modify the input picture structures (the pictures are copied into the encoder as the first step of encode). Encoder allocation is a reentrant function, so multiple encoders may be safely allocated in a single process. The encoder access functions are not reentrant for a single encoder, so the recommended use case is to allocate one client thread per encoder instance (one thread for all encoder instances is possible, but some encoder access functions are blocking and thus this would be less efficient). .. Note:: There is one caveat to having multiple encoders within a single process. All of the encoders must use the same maximum CTU size because many global variables are configured based on this size. Encoder allocation will fail if a mis-matched CTU size is attempted. If no encoders are open, **x265_cleanup()** can be called to reset the configured CTU size so a new size can be used. An encoder is allocated by calling **x265_encoder_open()**:: /* x265_encoder_open: * create a new encoder handler, all parameters from x265_param are copied */ x265_encoder* x265_encoder_open(x265_param *); The returned pointer is then passed to all of the functions pertaining to this encode. A large amount of memory is allocated during this function call, but the encoder will continue to allocate memory as the first pictures are passed to the encoder; until its pool of picture structures is large enough to handle all of the pictures it must keep internally. The pool size is determined by the lookahead depth, the number of frame threads, and the maximum number of references. As indicated in the comment, **x265_param** is copied internally so the user may release their copy after allocating the encoder. Changes made to their copy of the param structure have no affect on the encoder after it has been allocated. Param ===== The **x265_param** structure describes everything the encoder needs to know about the input pictures and the output bitstream and most everything in between. The recommended way to handle these param structures is to allocate them from libx265 via:: /* x265_param_alloc: * Allocates an x265_param instance. The returned param structure is not * special in any way, but using this method together with x265_param_free() * and x265_param_parse() to set values by name allows the application to treat * x265_param as an opaque data struct for version safety */ x265_param *x265_param_alloc(); In this way, your application does not need to know the exact size of the param structure (the build of x265 could potentially be a bit newer than the copy of :file:`x265.h` that your application compiled against). Next you perform the initial *rough cut* configuration of the encoder by chosing a performance preset and optional tune factor **x265_preset_names** and **x265_tune_names** respectively hold the string names of the presets and tune factors (see :ref:`presets ` for more detail on presets and tune factors):: /* returns 0 on success, negative on failure (e.g. invalid preset/tune name). */ int x265_param_default_preset(x265_param *, const char *preset, const char *tune); Now you may optionally specify a profile. **x265_profile_names** contains the string names this function accepts:: /* (can be NULL, in which case the function will do nothing) * returns 0 on success, negative on failure (e.g. invalid profile name). */ int x265_param_apply_profile(x265_param *, const char *profile); Finally you configure any remaining options by name using repeated calls to:: /* x265_param_parse: * set one parameter by name. * returns 0 on success, or returns one of the following errors. * note: BAD_VALUE occurs only if it can't even parse the value, * numerical range is not checked until x265_encoder_open(). * value=NULL means "true" for boolean options, but is a BAD_VALUE for non-booleans. */ #define X265_PARAM_BAD_NAME (-1) #define X265_PARAM_BAD_VALUE (-2) int x265_param_parse(x265_param *p, const char *name, const char *value); See :ref:`string options ` for the list of options (and their descriptions) which can be set by **x265_param_parse()**. After the encoder has been created, you may release the param structure:: /* x265_param_free: * Use x265_param_free() to release storage for an x265_param instance * allocated by x265_param_alloc() */ void x265_param_free(x265_param *); .. Note:: Using these methods to allocate and release the param structures helps future-proof your code in many ways, but the x265 API is versioned in such a way that we prevent linkage against a build of x265 that does not match the version of the header you are compiling against (unless you use x265_api_query() to acquire the library's interfaces). This is function of the X265_BUILD macro. **x265_encoder_parameters()** may be used to get a copy of the param structure from the encoder after it has been opened, in order to see the changes made to the parameters for auto-detection and other reasons:: /* x265_encoder_parameters: * copies the current internal set of parameters to the pointer provided * by the caller. useful when the calling application needs to know * how x265_encoder_open has changed the parameters. * note that the data accessible through pointers in the returned param struct * (e.g. filenames) should not be modified by the calling application. */ void x265_encoder_parameters(x265_encoder *, x265_param *); **x265_encoder_reconfig()** may be used to reconfigure encoder parameters mid-encode:: /* x265_encoder_reconfig: * used to modify encoder parameters. * various parameters from x265_param are copied. * this takes effect immediately, on whichever frame is encoded next; * returns negative on parameter validation error, 0 on successful reconfigure * and 1 when a reconfigure is already in progress. * * not all parameters can be changed; see the actual function for a * detailed breakdown. since not all parameters can be changed, moving * from preset to preset may not always fully copy all relevant parameters, * but should still work usably in practice. however, more so than for * other presets, many of the speed shortcuts used in ultrafast cannot be * switched out of; using reconfig to switch between ultrafast and other * presets is not recommended without a more fine-grained breakdown of * parameters to take this into account. */ int x265_encoder_reconfig(x265_encoder *, x265_param *); Pictures ======== Raw pictures are passed to the encoder via the **x265_picture** structure. Just like the param structure we recommend you allocate this structure from the encoder to avoid potential size mismatches:: /* x265_picture_alloc: * Allocates an x265_picture instance. The returned picture structure is not * special in any way, but using this method together with x265_picture_free() * and x265_picture_init() allows some version safety. New picture fields will * always be added to the end of x265_picture */ x265_picture *x265_picture_alloc(); Regardless of whether you allocate your picture structure this way or whether you simply declare it on the stack, your next step is to initialize the structure via:: /*** * Initialize an x265_picture structure to default values. It sets the pixel * depth and color space to the encoder's internal values and sets the slice * type to auto - so the lookahead will determine slice type. */ void x265_picture_init(x265_param *param, x265_picture *pic); x265 does not perform any color space conversions, so the raw picture's color space (chroma sampling) must match the color space specified in the param structure used to allocate the encoder. **x265_picture_init** initializes this field to the internal color space and it is best to leave it unmodified. The picture bit depth is initialized to be the encoder's internal bit depth but this value should be changed to the actual depth of the pixels being passed into the encoder. If the picture bit depth is more than 8, the encoder assumes two bytes are used to represent each sample (little-endian shorts). The user is responsible for setting the plane pointers and plane strides (in units of bytes, not pixels). The presentation time stamp (**pts**) is optional, depending on whether you need accurate decode time stamps (**dts**) on output. If you wish to override the lookahead or rate control for a given picture you may specify a slicetype other than X265_TYPE_AUTO, or a forceQP value other than 0. x265 does not modify the picture structure provided as input, so you may reuse a single **x265_picture** for all pictures passed to a single encoder, or even all pictures passed to multiple encoders. Structures allocated from the library should eventually be released:: /* x265_picture_free: * Use x265_picture_free() to release storage for an x265_picture instance * allocated by x265_picture_alloc() */ void x265_picture_free(x265_picture *); Analysis Buffers ================ Analysis information can be saved and reused to between encodes of the same video sequence (generally for multiple bitrate encodes). The best results are attained by saving the analysis information of the highest bitrate encode and reuse it in lower bitrate encodes. When saving or loading analysis data, buffers must be allocated for every picture passed into the encoder using:: /* x265_alloc_analysis_data: * Allocate memory to hold analysis meta data, returns 1 on success else 0 */ int x265_alloc_analysis_data(x265_picture*); Note that this is very different from the typical semantics of **x265_picture**, which can be reused many times. The analysis buffers must be re-allocated for every input picture. Analysis buffers passed to the encoder are owned by the encoder until they pass the buffers back via an output **x265_picture**. The user is responsible for releasing the buffers when they are finished with them via:: /* x265_free_analysis_data: * Use x265_free_analysis_data to release storage of members allocated by * x265_alloc_analysis_data */ void x265_free_analysis_data(x265_picture*); Encode Process ============== The output of the encoder is a series of NAL packets, which are always returned concatenated in consecutive memory. HEVC streams have SPS and PPS and VPS headers which describe how the following packets are to be decoded. If you specified :option:`--repeat-headers` then those headers will be output with every keyframe. Otherwise you must explicitly query those headers using:: /* x265_encoder_headers: * return the SPS and PPS that will be used for the whole stream. * *pi_nal is the number of NAL units outputted in pp_nal. * returns negative on error, total byte size of payload data on success * the payloads of all output NALs are guaranteed to be sequential in memory. */ int x265_encoder_headers(x265_encoder *, x265_nal **pp_nal, uint32_t *pi_nal); Now we get to the main encode loop. Raw input pictures are passed to the encoder in display order via:: /* x265_encoder_encode: * encode one picture. * *pi_nal is the number of NAL units outputted in pp_nal. * returns negative on error, zero if no NAL units returned. * the payloads of all output NALs are guaranteed to be sequential in memory. */ int x265_encoder_encode(x265_encoder *encoder, x265_nal **pp_nal, uint32_t *pi_nal, x265_picture *pic_in, x265_picture *pic_out); These pictures are queued up until the lookahead is full, and then the frame encoders in turn are filled, and then finally you begin receiving a output NALs (corresponding to a single output picture) with each input picture you pass into the encoder. Once the pipeline is completely full, **x265_encoder_encode()** will block until the next output picture is complete. .. note:: Optionally, if the pointer of a second **x265_picture** structure is provided, the encoder will fill it with data pertaining to the output picture corresponding to the output NALs, including the recontructed image, POC and decode timestamp. These pictures will be in encode (or decode) order. The encoder will also write corresponding frame encode statistics into **x265_frame_stats**. When the last of the raw input pictures has been sent to the encoder, **x265_encoder_encode()** must still be called repeatedly with a *pic_in* argument of 0, indicating a pipeline flush, until the function returns a value less than or equal to 0 (indicating the output bitstream is complete). At any time during this process, the application may query running statistics from the encoder:: /* x265_encoder_get_stats: * returns encoder statistics */ void x265_encoder_get_stats(x265_encoder *encoder, x265_stats *, uint32_t statsSizeBytes); Cleanup ======= Finally, the encoder must be closed in order to free all of its resources. An encoder that has been flushed cannot be restarted and reused. Once **x265_encoder_close()** has been called, the encoder handle must be discarded:: /* x265_encoder_close: * close an encoder handler */ void x265_encoder_close(x265_encoder *); When the application has completed all encodes, it should call **x265_cleanup()** to free process global, particularly if a memory-leak detection tool is being used. **x265_cleanup()** also resets the saved CTU size so it will be possible to create a new encoder with a different CTU size:: /* x265_cleanup: * release library static allocations, reset configured CTU size */ void x265_cleanup(void); Multi-library Interface ======================= If your application might want to make a runtime bit-depth selection, it will need to use one of these bit-depth introspection interfaces which returns an API structure containing the public function entry points and constants. Instead of directly using all of the **x265_** methods documented above, you query an x265_api structure from your libx265 and then use the function pointers of the same name (minus the **x265_** prefix) within that structure. For instance **x265_param_default()** becomes **api->param_default()**. x265_api_get ------------ The first bit-depth instrospecton method is x265_api_get(). It designed for applications that might statically link with libx265, or will at least be tied to a particular SONAME or API version:: /* x265_api_get: * Retrieve the programming interface for a linked x265 library. * May return NULL if no library is available that supports the * requested bit depth. If bitDepth is 0, the function is guarunteed * to return a non-NULL x265_api pointer from the system default * libx265 */ const x265_api* x265_api_get(int bitDepth); Like **x265_encoder_encode()**, this function has the build number automatically appended to the function name via macros. This ties your application to a particular binary API version of libx265 (the one you compile against). If you attempt to link with a libx265 with a different API version number, the link will fail. Obviously this has no meaningful effect on applications which statically link to libx265. x265_api_query -------------- The second bit-depth introspection method is designed for applications which need more flexibility in API versioning. If you use **x265_api_query()** and dynamically link to libx265 at runtime (using dlopen() on POSIX or LoadLibrary() on Windows) your application is no longer directly tied to the API version that it was compiled against:: /* x265_api_query: * Retrieve the programming interface for a linked x265 library, like * x265_api_get(), except this function accepts X265_BUILD as the second * argument rather than using the build number as part of the function name. * Applications which dynamically link to libx265 can use this interface to * query the library API and achieve a relative amount of version skew * flexibility. The function may return NULL if the library determines that * the apiVersion that your application was compiled against is not compatible * with the library you have linked with. * * api_major_version will be incremented any time non-backward compatible * changes are made to any public structures or functions. If * api_major_version does not match X265_MAJOR_VERSION from the x265.h your * application compiled against, your application must not use the returned * x265_api pointer. * * Users of this API *must* also validate the sizes of any structures which * are not treated as opaque in application code. For instance, if your * application dereferences a x265_param pointer, then it must check that * api->sizeof_param matches the sizeof(x265_param) that your application * compiled with. */ const x265_api* x265_api_query(int bitDepth, int apiVersion, int* err); A number of validations must be performed on the returned API structure in order to determine if it is safe for use by your application. If you do not perform these checks, your application is liable to crash:: if (api->api_major_version != X265_MAJOR_VERSION) /* do not use */ if (api->sizeof_param != sizeof(x265_param)) /* do not use */ if (api->sizeof_picture != sizeof(x265_picture)) /* do not use */ if (api->sizeof_stats != sizeof(x265_stats)) /* do not use */ if (api->sizeof_zone != sizeof(x265_zone)) /* do not use */ etc. Note that if your application does not directly allocate or dereference one of these structures, if it treats the structure as opaque or does not use it at all, then it can skip the size check for that structure. In particular, if your application uses api->param_alloc(), api->param_free(), api->param_parse(), etc and never directly accesses any x265_param fields, then it can skip the check on the sizeof(x265_parm) and thereby ignore changes to that structure (which account for a large percentage of X265_BUILD bumps). Build Implications ------------------ By default libx265 will place all of its internal C++ classes and functions within an x265 namespace and export all of the C functions documented in this file. Obviously this prevents 8bit and 10bit builds of libx265 from being statically linked into a single binary, all of those symbols would collide. However, if you set the EXPORT_C_API cmake option to OFF then libx265 will use a bit-depth specific namespace and prefix for its assembly functions (x265_8bit, x265_10bit or x265_12bit) and export no C functions. In this way you can build one or more libx265 libraries without any exported C interface and link them into a libx265 build that does export a C interface. The build which exported the C functions becomes the *default* bit depth for the combined library, and the other bit depths are available via the bit-depth introspection methods. .. Note:: When setting EXPORT_C_API cmake option to OFF, it is recommended to also set ENABLE_SHARED and ENABLE_CLI to OFF to prevent build problems. We only need the static library from these builds. If an application requests a bit-depth that is not supported by the default library or any of the additionally linked libraries, the introspection method will fall-back to an attempt to dynamically bind a shared library with a name appropriate for the requested bit-depth:: 8-bit: libx265_main 10-bit: libx265_main10 12-bit: libx265_main12 If the profile-named library is not found, it will then try to bind a generic libx265 in the hopes that it is a multilib library with all bit depths. Packaging and Distribution -------------------------- We recommend that packagers distribute a single combined shared/static library build which includes all the bit depth libraries linked together. See the multilib scripts in our :file:`build/` subdirectories for examples of how to affect these combined library builds. It is the packager's discretion which bit-depth exports the public C functions and thus becomes the default bit-depth for the combined library. .. Note:: Windows packagers might want to build libx265 with WINXP_SUPPORT enabled. This makes the resulting binaries functional on XP and Vista. Without this flag, the minimum supported host O/S is Windows 7. Also note that binaries built with WINXP_SUPPORT will *not* have NUMA support and they will have slightly less performance. STATIC_LINK_CRT is also recommended so end-users will not need to install any additional MSVC C runtime libraries. x265_2.1/doc/reST/cli.rst0000644000000000000000000021637512772433167015055 0ustar rootroot00000000000000********************* Command Line Options ********************* .. _string-options-ref: Note that unless an option is listed as **CLI ONLY** the option is also supported by x265_param_parse(). The CLI uses getopt to parse the command line options so the short or long versions may be used and the long options may be truncated to the shortest unambiguous abbreviation. Users of the API must pass x265_param_parse() the full option name. Preset and tune have special implications. The API user must call x265_param_default_preset() with the preset and tune parameters they wish to use, prior to calling x265_param_parse() to set any additional fields. The CLI does this for the user implicitly, so all CLI options are applied after the user's preset and tune choices, regardless of the order of the arguments on the command line. If there is an extra command line argument (not an option or an option value) the CLI will treat it as the input filename. This effectively makes the :option:`--input` specifier optional for the input file. If there are two extra arguments, the second is treated as the output bitstream filename, making :option:`--output` also optional if the input filename was implied. This makes :command:`x265 in.y4m out.hevc` a valid command line. If there are more than two extra arguments, the CLI will consider this an error and abort. Generally, when an option expects a string value from a list of strings the user may specify the integer ordinal of the value they desire. ie: :option:`--log-level` 3 is equivalent to :option:`--log-level` debug. Executable Options ================== .. option:: --help, -h Display help text **CLI ONLY** .. option:: --version, -V Display version details **CLI ONLY** Command line executable return codes:: 0. encode successful 1. unable to parse command line 2. unable to open encoder 3. unable to generate stream headers 4. encoder abort 5. unable to open csv file Logging/Statistic Options ========================= .. option:: --log-level Controls the level of information displayed on the console. Debug level enables per-frame QP, metric, and bitrate logging. Full level enables hash and weight logging. -1 disables all logging, except certain fatal errors, and can be specified by the string "none". 0. error 1. warning 2. info **(default)** 3. debug 4. full .. option:: --no-progress Disable periodic progress reports from the CLI **CLI ONLY** .. option:: --csv Write encoding statistics to a Comma Separated Values log file. Creates the file if it doesn't already exist. If :option:`--csv-log-level` is 0, it adds one line per run. If :option:`--csv-log-level` is greater than 0, it writes one line per frame. Default none Several frame performance statistics are available when :option:`--csv-log-level` is greater than or equal to 2: **DecideWait ms** number of milliseconds the frame encoder had to wait, since the previous frame was retrieved by the API thread, before a new frame has been given to it. This is the latency introduced by slicetype decisions (lookahead). **Row0Wait ms** number of milliseconds since the frame encoder received a frame to encode before its first row of CTUs is allowed to begin compression. This is the latency introduced by reference frames making reconstructed and filtered rows available. **Wall time ms** number of milliseconds between the first CTU being ready to be compressed and the entire frame being compressed and the output NALs being completed. **Ref Wait Wall ms** number of milliseconds between the first reference row being available and the last reference row becoming available. **Total CTU time ms** the total time (measured in milliseconds) spent by worker threads compressing and filtering CTUs for this frame. **Stall Time ms** the number of milliseconds of the reported wall time that were spent with zero worker threads, aka all compression was completely stalled. **Avg WPP** the average number of worker threads working on this frame, at any given time. This value is sampled at the completion of each CTU. This shows the effectiveness of Wavefront Parallel Processing. **Row Blocks** the number of times a worker thread had to abandon the row of CTUs it was encoding because the row above it was not far enough ahead for the necessary reference data to be available. This is more of a problem for P frames where some blocks are much more expensive than others. **CLI ONLY** .. option:: --csv-log-level Controls the level of detail (and size) of --csv log files 0. summary **(default)** 1. frame level logging 2. frame level logging with performance statistics **CLI ONLY** .. option:: --ssim, --no-ssim Calculate and report Structural Similarity values. It is recommended to use :option:`--tune` ssim if you are measuring ssim, else the results should not be used for comparison purposes. Default disabled .. option:: --psnr, --no-psnr Calculate and report Peak Signal to Noise Ratio. It is recommended to use :option:`--tune` psnr if you are measuring PSNR, else the results should not be used for comparison purposes. Default disabled Performance Options =================== .. option:: --asm , --no-asm x265 will use all detected CPU SIMD architectures by default. You can disable all assembly by using :option:`--no-asm` or you can specify a comma separated list of SIMD architectures to use, matching these strings: MMX2, SSE, SSE2, SSE3, SSSE3, SSE4, SSE4.1, SSE4.2, AVX, XOP, FMA4, AVX2, FMA3 Some higher architectures imply lower ones being present, this is handled implicitly. One may also directly supply the CPU capability bitmap as an integer. Note that by specifying this option you are overriding x265's CPU detection and it is possible to do this wrong. You can cause encoder crashes by specifying SIMD architectures which are not supported on your CPU. Default: auto-detected SIMD architectures .. option:: --frame-threads, -F Number of concurrently encoded frames. Using a single frame thread gives a slight improvement in compression, since the entire reference frames are always available for motion compensation, but it has severe performance implications. Default is an autodetected count based on the number of CPU cores and whether WPP is enabled or not. Over-allocation of frame threads will not improve performance, it will generally just increase memory use. **Values:** any value between 0 and 16. Default is 0, auto-detect .. option:: --pools , --numa-pools Comma seperated list of threads per NUMA node. If "none", then no worker pools are created and only frame parallelism is possible. If NULL or "" (default) x265 will use all available threads on each NUMA node:: '+' is a special value indicating all cores detected on the node '*' is a special value indicating all cores detected on the node and all remaining nodes '-' is a special value indicating no cores on the node, same as '0' example strings for a 4-node system:: "" - default, unspecified, all numa nodes are used for thread pools "*" - same as default "none" - no thread pools are created, only frame parallelism possible "-" - same as "none" "10" - allocate one pool, using up to 10 cores on node 0 "-,+" - allocate one pool, using all cores on node 1 "+,-,+" - allocate one pool, using only cores on nodes 0 and 2 "+,-,+,-" - allocate one pool, using only cores on nodes 0 and 2 "-,*" - allocate one pool, using all cores on nodes 1, 2 and 3 "8,8,8,8" - allocate four pools with up to 8 threads in each pool "8,+,+,+" - allocate two pools, the first with 8 threads on node 0, and the second with all cores on node 1,2,3 A thread pool dedicated to a given NUMA node is enabled only when the number of threads to be created on that NUMA node is explicitly mentioned in that corresponding position with the --pools option. Else, all threads are spawned from a single pool. The total number of threads will be determined by the number of threads assigned to the enabled NUMA nodes for that pool. The worker threads are be given affinity to all the enabled NUMA nodes for that pool and may migrate between them, unless explicitly specified as described above. In the case that any threadpool has more than 64 threads, the threadpool may be broken down into multiple pools of 64 threads each; on 32-bit machines, this number is 32. All pools are given affinity to the NUMA nodes on which the original pool had affinity. For performance reasons, the last thread pool is spawned only if it has more than 32 threads for 64-bit machines, or 16 for 32-bit machines. If the total number of threads in the system doesn't obey this constraint, we may spawn fewer threads than cores which has been emperically shown to be better for performance. If the four pool features: :option:`--wpp`, :option:`--pmode`, :option:`--pme` and :option:`--lookahead-slices` are all disabled, then :option:`--pools` is ignored and no thread pools are created. If "none" is specified, then all four of the thread pool features are implicitly disabled. Frame encoders are distributed between the available thread pools, and the encoder will never generate more thread pools than :option:`--frame-threads`. The pools are used for WPP and for distributed analysis and motion search. On Windows, the native APIs offer sufficient functionality to discover the NUMA topology and enforce the thread affinity that libx265 needs (so long as you have not chosen to target XP or Vista), but on POSIX systems it relies on libnuma for this functionality. If your target POSIX system is single socket, then building without libnuma is a perfectly reasonable option, as it will have no effect on the runtime behavior. On a multiple-socket system, a POSIX build of libx265 without libnuma will be less work efficient. See :ref:`thread pools ` for more detail. Default "", one pool is created across all available NUMA nodes, with one thread allocated per detected hardware thread (logical CPU cores). In the case that the total number of threads is more than the maximum size that ATOMIC operations can handle (32 for 32-bit compiles, and 64 for 64-bit compiles), multiple thread pools may be spawned subject to the performance constraint described above. Note that the string value will need to be escaped or quoted to protect against shell expansion on many platforms .. option:: --wpp, --no-wpp Enable Wavefront Parallel Processing. The encoder may begin encoding a row as soon as the row above it is at least two CTUs ahead in the encode process. This gives a 3-5x gain in parallelism for about 1% overhead in compression efficiency. This feature is implicitly disabled when no thread pool is present. Default: Enabled .. option:: --pmode, --no-pmode Parallel mode decision, or distributed mode analysis. When enabled the encoder will distribute the analysis work of each CU (merge, inter, intra) across multiple worker threads. Only recommended if x265 is not already saturating the CPU cores. In RD levels 3 and 4 it will be most effective if --rect is enabled. At RD levels 5 and 6 there is generally always enough work to distribute to warrant the overhead, assuming your CPUs are not already saturated. --pmode will increase utilization without reducing compression efficiency. In fact, since the modes are all measured in parallel it makes certain early-outs impractical and thus you usually get slightly better compression when it is enabled (at the expense of not skipping improbable modes). This bypassing of early-outs can cause pmode to slow down encodes, especially at faster presets. This feature is implicitly disabled when no thread pool is present. Default disabled .. option:: --pme, --no-pme Parallel motion estimation. When enabled the encoder will distribute motion estimation across multiple worker threads when more than two references require motion searches for a given CU. Only recommended if x265 is not already saturating CPU cores. :option:`--pmode` is much more effective than this option, since the amount of work it distributes is substantially higher. With --pme it is not unusual for the overhead of distributing the work to outweigh the parallelism benefits. This feature is implicitly disabled when no thread pool is present. --pme will increase utilization on many core systems with no effect on the output bitstream. Default disabled .. option:: --preset, -p Sets parameters to preselected values, trading off compression efficiency against encoding speed. These parameters are applied before all other input parameters are applied, and so you can override any parameters that these values control. See :ref:`presets ` for more detail. 0. ultrafast 1. superfast 2. veryfast 3. faster 4. fast 5. medium **(default)** 6. slow 7. slower 8. veryslow 9. placebo .. option:: --tune, -t Tune the settings for a particular type of source or situation. The changes will be applied after :option:`--preset` but before all other parameters. Default none. See :ref:`tunings ` for more detail. **Values:** psnr, ssim, grain, zero-latency, fast-decode. .. option:: --slices Encode each incoming frame as multiple parallel slices that may be decoded independently. Support available only for rectangular slices that cover the entire width of the image. Recommended for improving encoder performance only if frame-parallelism and WPP are unable to maximize utilization on given hardware. Default: 1 slice per frame. **Experimental feature** Input/Output File Options ========================= These options all describe the input video sequence or, in the case of :option:`--dither`, operations that are performed on the sequence prior to encode. All options dealing with files (names, formats, offsets or frame counts) are only applicable to the CLI application. .. option:: --input Input filename, only raw YUV or Y4M supported. Use single dash for stdin. This option name will be implied for the first "extra" command line argument. **CLI ONLY** .. option:: --y4m Parse input stream as YUV4MPEG2 regardless of file extension, primarily intended for use with stdin (ie: :option:`--input` - :option:`--y4m`). This option is implied if the input filename has a ".y4m" extension **CLI ONLY** .. option:: --input-depth YUV only: Bit-depth of input file or stream **Values:** any value between 8 and 16. Default is internal depth. **CLI ONLY** .. option:: --frames The number of frames intended to be encoded. It may be left unspecified, but when it is specified rate control can make use of this information. It is also used to determine if an encode is actually a stillpicture profile encode (single frame) .. option:: --dither Enable high quality downscaling to the encoder's internal bitdepth. Dithering is based on the diffusion of errors from one row of pixels to the next row of pixels in a picture. Only applicable when the input bit depth is larger than 8bits. Default disabled **CLI ONLY** .. option:: --input-res YUV only: Source picture size [w x h] **CLI ONLY** .. option:: --input-csp Chroma Subsampling (YUV only): Only 4:0:0(monochrome), 4:2:0, 4:2:2, and 4:4:4 are supported at this time. The chroma subsampling format of your input must match your desired output chroma subsampling format (libx265 will not perform any chroma subsampling conversion), and it must be supported by the HEVC profile you have specified. 0. i400 (4:0:0 monochrome) - Not supported by Main or Main10 profiles 1. i420 (4:2:0 default) - Supported by all HEVC profiles 2. i422 (4:2:2) - Not supported by Main, Main10 and Main12 profiles 3. i444 (4:4:4) - Supported by Main 4:4:4, Main 4:4:4 10, Main 4:4:4 12, Main 4:4:4 16 Intra profiles 4. nv12 5. nv16 .. option:: --fps YUV only: Source frame rate **Range of values:** positive int or float, or num/denom .. option:: --interlace , --no-interlace 0. progressive pictures **(default)** 1. top field first 2. bottom field first HEVC encodes interlaced content as fields. Fields must be provided to the encoder in the correct temporal order. The source dimensions must be field dimensions and the FPS must be in units of fields per second. The decoder must re-combine the fields in their correct orientation for display. .. option:: --seek Number of frames to skip at start of input file. Default 0 **CLI ONLY** .. option:: --frames, -f Number of frames of input sequence to be encoded. Default 0 (all) **CLI ONLY** .. option:: --output, -o Bitstream output file name. If there are two extra CLI options, the first is implicitly the input filename and the second is the output filename, making the :option:`--output` option optional. The output file will always contain a raw HEVC bitstream, the CLI does not support any container file formats. **CLI ONLY** .. option:: --output-depth, -D 8|10|12 Bitdepth of output HEVC bitstream, which is also the internal bit depth of the encoder. If the requested bit depth is not the bit depth of the linked libx265, it will attempt to bind libx265_main for an 8bit encoder, libx265_main10 for a 10bit encoder, or libx265_main12 for a 12bit encoder, with the same API version as the linked libx265. If the output depth is not specified but :option:`--profile` is specified, the output depth will be derived from the profile name. **CLI ONLY** Profile, Level, Tier ==================== .. option:: --profile, -P Enforce the requirements of the specified profile, ensuring the output stream will be decodable by a decoder which supports that profile. May abort the encode if the specified profile is impossible to be supported by the compile options chosen for the encoder (a high bit depth encoder will be unable to output bitstreams compliant with Main or MainStillPicture). The following profiles are supported in x265. 8bit profiles:: * main, main-intra, mainstillpicture (or msp for short) * main444-8, main444-intra, main444-stillpicture See note below on signaling intra and stillpicture profiles. 10bit profiles:: * main10, main10-intra * main422-10, main422-10-intra * main444-10, main444-10-intra 12bit profiles:: * main12, main12-intra * main422-12, main422-12-intra * main444-12, main444-12-intra **CLI ONLY** API users must call x265_param_apply_profile() after configuring their param structure. Any changes made to the param structure after this call might make the encode non-compliant. The CLI application will derive the output bit depth from the profile name if :option:`--output-depth` is not specified. .. option:: --level-idc Minimum decoder requirement level. Defaults to 0, which implies auto-detection by the encoder. If specified, the encoder will attempt to bring the encode specifications within that specified level. If the encoder is unable to reach the level it issues a warning and aborts the encode. If the requested requirement level is higher than the actual level, the actual requirement level is signaled. Beware, specifying a decoder level will force the encoder to enable VBV for constant rate factor encodes, which may introduce non-determinism. The value is specified as a float or as an integer with the level times 10, for example level **5.1** is specified as "5.1" or "51", and level **5.0** is specified as "5.0" or "50". Annex A levels: 1, 2, 2.1, 3, 3.1, 4, 4.1, 5, 5.1, 5.2, 6, 6.1, 6.2, 8.5 .. option:: --high-tier, --no-high-tier If :option:`--level-idc` has been specified, --high-tier allows the support of high tier at that level. The encoder will first attempt to encode at the specified level, main tier first, turning on high tier only if necessary and available at that level.If your requested level does not support a High tier, high tier will not be supported. If --no-high-tier has been specified, then the encoder will attempt to encode only at the main tier. Default: enabled .. option:: --ref <1..16> Max number of L0 references to be allowed. This number has a linear multiplier effect on the amount of work performed in motion search, but will generally have a beneficial affect on compression and distortion. Note that x265 allows up to 16 L0 references but the HEVC specification only allows a maximum of 8 total reference frames. So if you have B frames enabled only 7 L0 refs are valid and if you have :option:`--b-pyramid` enabled (which is enabled by default in all presets), then only 6 L0 refs are the maximum allowed by the HEVC specification. If x265 detects that the total reference count is greater than 8, it will issue a warning that the resulting stream is non-compliant and it signals the stream as profile NONE and level NONE and will abort the encode unless :option:`--allow-non-conformance` it specified. Compliant HEVC decoders may refuse to decode such streams. Default 3 .. option:: --allow-non-conformance, --no-allow-non-conformance Allow libx265 to generate a bitstream with profile and level NONE. By default it will abort any encode which does not meet strict level compliance. The two most likely causes for non-conformance are :option:`--ctu` being too small, :option:`--ref` being too high, or the bitrate or resolution being out of specification. Default: disabled .. option:: --uhd-bd Enable Ultra HD Blu-ray format support. If specified with incompatible encoding options, the encoder will attempt to modify/set the right encode specifications. If the encoder is unable to do so, this option will be turned OFF. Highly experimental. Default: disabled .. note:: :option:`--profile`, :option:`--level-idc`, and :option:`--high-tier` are only intended for use when you are targeting a particular decoder (or decoders) with fixed resource limitations and must constrain the bitstream within those limits. Specifying a profile or level may lower the encode quality parameters to meet those requirements but it will never raise them. It may enable VBV constraints on a CRF encode. Also note that x265 determines the decoder requirement profile and level in three steps. First, the user configures an x265_param structure with their suggested encoder options and then optionally calls x265_param_apply_profile() to enforce a specific profile (main, main10, etc). Second, an encoder is created from this x265_param instance and the :option:`--level-idc` and :option:`--high-tier` parameters are used to reduce bitrate or other features in order to enforce the target level. Finally, the encoder re-examines the final set of parameters and detects the actual minimum decoder requirement level and this is what is signaled in the bitstream headers. The detected decoder level will only use High tier if the user specified a High tier level. The signaled profile will be determined by the encoder's internal bitdepth and input color space. If :option:`--keyint` is 0 or 1, then an intra variant of the profile will be signaled. If :option:`--total-frames` is 1, then a stillpicture variant will be signaled, but this parameter is not always set by applications, particularly not when the CLI uses stdin streaming or when libx265 is used by third-party applications. Mode decision / Analysis ======================== .. option:: --rd <1..6> Level of RDO in mode decision. The higher the value, the more exhaustive the analysis and the more rate distortion optimization is used. The lower the value the faster the encode, the higher the value the smaller the bitstream (in general). Default 3 Note that this table aims for accuracy, but is not necessarily our final target behavior for each mode. +-------+---------------------------------------------------------------+ | Level | Description | +=======+===============================================================+ | 0 | sa8d mode and split decisions, intra w/ source pixels, | | | currently not supported | +-------+---------------------------------------------------------------+ | 1 | recon generated (better intra), RDO merge/skip selection | +-------+---------------------------------------------------------------+ | 2 | RDO splits and merge/skip selection | +-------+---------------------------------------------------------------+ | 3 | RDO mode and split decisions, chroma residual used for sa8d | +-------+---------------------------------------------------------------+ | 4 | Currently same as 3 | +-------+---------------------------------------------------------------+ | 5 | Adds RDO prediction decisions | +-------+---------------------------------------------------------------+ | 6 | Currently same as 5 | +-------+---------------------------------------------------------------+ **Range of values:** 1: least .. 6: full RDO analysis Options which affect the coding unit quad-tree, sometimes referred to as the prediction quad-tree. .. option:: --ctu, -s <64|32|16> Maximum CU size (width and height). The larger the maximum CU size, the more efficiently x265 can encode flat areas of the picture, giving large reductions in bitrate. However this comes at a loss of parallelism with fewer rows of CUs that can be encoded in parallel, and less frame parallelism as well. Because of this the faster presets use a CU size of 32. Default: 64 .. option:: --min-cu-size <64|32|16|8> Minimum CU size (width and height). By using 16 or 32 the encoder will not analyze the cost of CUs below that minimum threshold, saving considerable amounts of compute with a predictable increase in bitrate. This setting has a large effect on performance on the faster presets. Default: 8 (minimum 8x8 CU for HEVC, best compression efficiency) .. note:: All encoders within a single process must use the same settings for the CU size range. :option:`--ctu` and :option:`--min-cu-size` must be consistent for all of them since the encoder configures several key global data structures based on this range. .. option:: --limit-refs <0|1|2|3> When set to X265_REF_LIMIT_DEPTH (1) x265 will limit the references analyzed at the current depth based on the references used to code the 4 sub-blocks at the next depth. For example, a 16x16 CU will only use the references used to code its four 8x8 CUs. When set to X265_REF_LIMIT_CU (2), the rectangular and asymmetrical partitions will only use references selected by the 2Nx2N motion search (including at the lowest depth which is otherwise unaffected by the depth limit). When set to 3 (X265_REF_LIMIT_DEPTH && X265_REF_LIMIT_CU), the 2Nx2N motion search at each depth will only use references from the split CUs and the rect/amp motion searches at that depth will only use the reference(s) selected by 2Nx2N. For all non-zero values of limit-refs, the current depth will evaluate intra mode (in inter slices), only if intra mode was chosen as the best mode for atleast one of the 4 sub-blocks. You can often increase the number of references you are using (within your decoder level limits) if you enable one or both of these flags. Default 3. .. option:: --limit-modes, --no-limit-modes When enabled, limit-modes will limit modes analyzed for each CU using cost metrics from the 4 sub-CUs. When multiple inter modes like :option:`--rect` and/or :option:`--amp` are enabled, this feature will use motion cost heuristics from the 4 sub-CUs to bypass modes that are unlikely to be the best choice. This can significantly improve performance when :option:`rect` and/or :option:`--amp` are enabled at minimal compression efficiency loss. .. option:: --rect, --no-rect Enable analysis of rectangular motion partitions Nx2N and 2NxN (50/50 splits, two directions). Default disabled .. option:: --amp, --no-amp Enable analysis of asymmetric motion partitions (75/25 splits, four directions). At RD levels 0 through 4, AMP partitions are only considered at CU sizes 32x32 and below. At RD levels 5 and 6, it will only consider AMP partitions as merge candidates (no motion search) at 64x64, and as merge or inter candidates below 64x64. The AMP partitions which are searched are derived from the current best inter partition. If Nx2N (vertical rectangular) is the best current prediction, then left and right asymmetrical splits will be evaluated. If 2NxN (horizontal rectangular) is the best current prediction, then top and bottom asymmetrical splits will be evaluated, If 2Nx2N is the best prediction, and the block is not a merge/skip, then all four AMP partitions are evaluated. This setting has no effect if rectangular partitions are disabled. Default disabled .. option:: --early-skip, --no-early-skip Measure 2Nx2N merge candidates first; if no residual is found, additional modes at that depth are not analysed. Default disabled .. option:: --rskip, --no-rskip This option determines early exit from CU depth recursion. When a skip CU is found, additional heuristics (depending on rd-level) are used to decide whether to terminate recursion. In rdlevels 5 and 6, comparison with inter2Nx2N is used, while at rdlevels 4 and neighbour costs are used to skip recursion. Provides minimal quality degradation at good performance gains when enabled. Default: enabled, disabled for :option:`--tune grain` .. option:: --fast-intra, --no-fast-intra Perform an initial scan of every fifth intra angular mode, then check modes +/- 2 distance from the best mode, then +/- 1 distance from the best mode, effectively performing a gradient descent. When enabled 10 modes in total are checked. When disabled all 33 angular modes are checked. Only applicable for :option:`--rd` levels 4 and below (medium preset and faster). .. option:: --b-intra, --no-b-intra Enables the evaluation of intra modes in B slices. Default disabled. .. option:: --cu-lossless, --no-cu-lossless For each CU, evaluate lossless (transform and quant bypass) encode of the best non-lossless mode option as a potential rate distortion optimization. If the global option :option:`--lossless` has been specified, all CUs will be encoded as lossless unconditionally regardless of whether this option was enabled. Default disabled. Only effective at RD levels 3 and above, which perform RDO mode decisions. .. option:: --tskip-fast, --no-tskip-fast Only evaluate transform skip for NxN intra predictions (4x4 blocks). Only applicable if transform skip is enabled. For chroma, only evaluate if luma used tskip. Inter block tskip analysis is unmodified. Default disabled .. option:: --rd-refine, --no-rd-refine For each analysed CU, calculate R-D cost on the best partition mode for a range of QP values, to find the optimal rounding effect. Default disabled. Only effective at RD levels 5 and 6 Analysis re-use options, to improve performance when encoding the same sequence multiple times (presumably at varying bitrates). The encoder will not reuse analysis if the resolution and slice type parameters do not match. .. option:: --analysis-mode Specify whether analysis information of each frame is output by encoder or input for reuse. By reading the analysis data writen by an earlier encode of the same sequence, substantial redundant work may be avoided. The following data may be stored and reused: I frames - split decisions and luma intra directions of all CUs. P/B frames - motion vectors are dumped at each depth for all CUs. **Values:** off(0), save(1): dump analysis data, load(2): read analysis data .. option:: --analysis-file Specify a filename for analysis data (see :option:`--analysis-mode`) If no filename is specified, x265_analysis.dat is used. Options which affect the transform unit quad-tree, sometimes referred to as the residual quad-tree (RQT). .. option:: --rdoq-level <0|1|2>, --no-rdoq-level Specify the amount of rate-distortion analysis to use within quantization:: At level 0 rate-distortion cost is not considered in quant At level 1 rate-distortion cost is used to find optimal rounding values for each level (and allows psy-rdoq to be effective). It trades-off the signaling cost of the coefficient vs its post-inverse quant distortion from the pre-quant coefficient. When :option:`--psy-rdoq` is enabled, this formula is biased in favor of more energy in the residual (larger coefficient absolute levels) At level 2 rate-distortion cost is used to make decimate decisions on each 4x4 coding group, including the cost of signaling the group within the group bitmap. If the total distortion of not signaling the entire coding group is less than the rate cost, the block is decimated. Next, it applies rate-distortion cost analysis to the last non-zero coefficient, which can result in many (or all) of the coding groups being decimated. Psy-rdoq is less effective at preserving energy when RDOQ is at level 2, since it only has influence over the level distortion costs. .. option:: --tu-intra-depth <1..4> The transform unit (residual) quad-tree begins with the same depth as the coding unit quad-tree, but the encoder may decide to further split the transform unit tree if it improves compression efficiency. This setting limits the number of extra recursion depth which can be attempted for intra coded units. Default: 1, which means the residual quad-tree is always at the same depth as the coded unit quad-tree Note that when the CU intra prediction is NxN (only possible with 8x8 CUs), a TU split is implied, and thus the residual quad-tree begins at 4x4 and cannot split any futhrer. .. option:: --tu-inter-depth <1..4> The transform unit (residual) quad-tree begins with the same depth as the coding unit quad-tree, but the encoder may decide to further split the transform unit tree if it improves compression efficiency. This setting limits the number of extra recursion depth which can be attempted for inter coded units. Default: 1. which means the residual quad-tree is always at the same depth as the coded unit quad-tree unless the CU was coded with rectangular or AMP partitions, in which case a TU split is implied and thus the residual quad-tree begins one layer below the CU quad-tree. .. option:: --nr-intra , --nr-inter Noise reduction - an adaptive deadzone applied after DCT (subtracting from DCT coefficients), before quantization. It does no pixel-level filtering, doesn't cross DCT block boundaries, has no overlap, The higher the strength value parameter, the more aggressively it will reduce noise. Enabling noise reduction will make outputs diverge between different numbers of frame threads. Outputs will be deterministic but the outputs of -F2 will no longer match the outputs of -F3, etc. **Values:** any value in range of 0 to 2000. Default 0 (disabled). .. option:: --tskip, --no-tskip Enable evaluation of transform skip (bypass DCT but still use quantization) coding for 4x4 TU coded blocks. Only effective at RD levels 3 and above, which perform RDO mode decisions. Default disabled .. option:: --rdpenalty <0..2> When set to 1, transform units of size 32x32 are given a 4x bit cost penalty compared to smaller transform units, in intra coded CUs in P or B slices. When set to 2, transform units of size 32x32 are not even attempted, unless otherwise required by the maximum recursion depth. For this option to be effective with 32x32 intra CUs, :option:`--tu-intra-depth` must be at least 2. For it to be effective with 64x64 intra CUs, :option:`--tu-intra-depth` must be at least 3. Note that in HEVC an intra transform unit (a block of the residual quad-tree) is also a prediction unit, meaning that the intra prediction signal is generated for each TU block, the residual subtracted and then coded. The coding unit simply provides the prediction modes that will be used when predicting all of the transform units within the CU. This means that when you prevent 32x32 intra transform units, you are preventing 32x32 intra predictions. Default 0, disabled. **Values:** 0:disabled 1:4x cost penalty 2:force splits .. option:: --max-tu-size <32|16|8|4> Maximum TU size (width and height). The residual can be more efficiently compressed by the DCT transform when the max TU size is larger, but at the expense of more computation. Transform unit quad-tree begins at the same depth of the coded tree unit, but if the maximum TU size is smaller than the CU size then transform QT begins at the depth of the max-tu-size. Default: 32. Temporal / motion search options ================================ .. option:: --max-merge <1..5> Maximum number of neighbor (spatial and temporal) candidate blocks that the encoder may consider for merging motion predictions. If a merge candidate results in no residual, it is immediately selected as a "skip". Otherwise the merge candidates are tested as part of motion estimation when searching for the least cost inter option. The max candidate number is encoded in the SPS and determines the bit cost of signaling merge CUs. Default 2 .. option:: --me Motion search method. Generally, the higher the number the harder the ME method will try to find an optimal match. Diamond search is the simplest. Hexagon search is a little better. Uneven Multi-Hexegon is an adaption of the search method used by x264 for slower presets. Star is a three step search adapted from the HM encoder: a star-pattern search followed by an optional radix scan followed by an optional star-search refinement. Full is an exhaustive search; an order of magnitude slower than all other searches but not much better than umh or star. 0. dia 1. hex **(default)** 2. umh 3. star 4. full .. option:: --subme, -m <0..7> Amount of subpel refinement to perform. The higher the number the more subpel iterations and steps are performed. Default 2 +----+------------+-----------+------------+-----------+-----------+ | -m | HPEL iters | HPEL dirs | QPEL iters | QPEL dirs | HPEL SATD | +====+============+===========+============+===========+===========+ | 0 | 1 | 4 | 0 | 4 | false | +----+------------+-----------+------------+-----------+-----------+ | 1 | 1 | 4 | 1 | 4 | false | +----+------------+-----------+------------+-----------+-----------+ | 2 | 1 | 4 | 1 | 4 | true | +----+------------+-----------+------------+-----------+-----------+ | 3 | 2 | 4 | 1 | 4 | true | +----+------------+-----------+------------+-----------+-----------+ | 4 | 2 | 4 | 2 | 4 | true | +----+------------+-----------+------------+-----------+-----------+ | 5 | 1 | 8 | 1 | 8 | true | +----+------------+-----------+------------+-----------+-----------+ | 6 | 2 | 8 | 1 | 8 | true | +----+------------+-----------+------------+-----------+-----------+ | 7 | 2 | 8 | 2 | 8 | true | +----+------------+-----------+------------+-----------+-----------+ At --subme values larger than 2, chroma residual cost is included in all subpel refinement steps and chroma residual is included in all motion estimation decisions (selecting the best reference picture in each list, and chosing between merge, uni-directional motion and bi-directional motion). The 'slow' preset is the first preset to enable the use of chroma residual. .. option:: --merange Motion search range. Default 57 The default is derived from the default CTU size (64) minus the luma interpolation half-length (4) minus maximum subpel distance (2) minus one extra pixel just in case the hex search method is used. If the search range were any larger than this, another CTU row of latency would be required for reference frames. **Range of values:** an integer from 0 to 32768 .. option:: --temporal-mvp, --no-temporal-mvp Enable temporal motion vector predictors in P and B slices. This enables the use of the motion vector from the collocated block in the previous frame to be used as a predictor. Default is enabled .. option:: --weightp, -w, --no-weightp Enable weighted prediction in P slices. This enables weighting analysis in the lookahead, which influences slice decisions, and enables weighting analysis in the main encoder which allows P reference samples to have a weight function applied to them prior to using them for motion compensation. In video which has lighting changes, it can give a large improvement in compression efficiency. Default is enabled .. option:: --weightb, --no-weightb Enable weighted prediction in B slices. Default disabled .. option:: --analyze-src-pics, --no-analyze-src-pics Enalbe motion estimation with source frame pixels, in this mode, motion estimation can be computed independently. Default disabled. Spatial/intra options ===================== .. option:: --strong-intra-smoothing, --no-strong-intra-smoothing Enable strong intra smoothing for 32x32 intra blocks. This flag performs bi-linear interpolation of the corner reference samples for a strong smoothing effect. The purpose is to prevent blocking or banding artifacts in regions with few/zero AC coefficients. Default enabled .. option:: --constrained-intra, --no-constrained-intra Constrained intra prediction. When generating intra predictions for blocks in inter slices, only intra-coded reference pixels are used. Inter-coded reference pixels are replaced with intra-coded neighbor pixels or default values. The general idea is to block the propagation of reference errors that may have resulted from lossy signals. Default disabled Psycho-visual options ===================== Left to its own devices, the encoder will make mode decisions based on a simple rate distortion formula, trading distortion for bitrate. This is generally effective except for the manner in which this distortion is measured. It tends to favor blurred reconstructed blocks over blocks which have wrong motion. The human eye generally prefers the wrong motion over the blur and thus x265 offers psycho-visual adjustments to the rate distortion algorithm. :option:`--psy-rd` will add an extra cost to reconstructed blocks which do not match the visual energy of the source block. The higher the strength of :option:`--psy-rd` the more strongly it will favor similar energy over blur and the more aggressively it will ignore rate distortion. If it is too high, it will introduce visal artifacts and increase bitrate enough for rate control to increase quantization globally, reducing overall quality. psy-rd will tend to reduce the use of blurred prediction modes, like DC and planar intra and bi-directional inter prediction. :option:`--psy-rdoq` will adjust the distortion cost used in rate-distortion optimized quantization (RDO quant), enabled by :option:`--rdoq-level` 1 or 2, favoring the preservation of energy in the reconstructed image. :option:`--psy-rdoq` prevents RDOQ from blurring all of the encoding options which psy-rd has to chose from. At low strength levels, psy-rdoq will influence the quantization level decisions, favoring higher AC energy in the reconstructed image. As psy-rdoq strength is increased, more non-zero coefficient levels are added and fewer coefficients are zeroed by RDOQ's rate distortion analysis. High levels of psy-rdoq can double the bitrate which can have a drastic effect on rate control, forcing higher overall QP, and can cause ringing artifacts. psy-rdoq is less accurate than psy-rd, it is biasing towards energy in general while psy-rd biases towards the energy of the source image. But very large psy-rdoq values can sometimes be beneficial. As a general rule, when both psycho-visual features are disabled, the encoder will tend to blur blocks in areas of difficult motion. Turning on small amounts of psy-rd and psy-rdoq will improve the perceived visual quality. Increasing psycho-visual strength further will improve quality and begin introducing artifacts and increase bitrate, which may force rate control to increase global QP. Finding the optimal psycho-visual parameters for a given video requires experimentation. Our recommended defaults (1.0 for both) are generally on the low end of the spectrum. The lower the bitrate, the lower the optimal psycho-visual settings. If the bitrate is too low for the psycho-visual settings, you will begin to see temporal artifacts (motion judder). This is caused when the encoder is forced to code skip blocks (no residual) in areas of difficult motion because it is the best option psycho-visually (they have great amounts of energy and no residual cost). One can lower psy-rd settings when judder is happening, and allow the encoder to use some blur in these areas of high motion. .. option:: --psy-rd Influence rate distortion optimizated mode decision to preserve the energy of the source image in the encoded image at the expense of compression efficiency. It only has effect on presets which use RDO-based mode decisions (:option:`--rd` 3 and above). 1.0 is a typical value. Default 2.0 **Range of values:** 0 .. 5.0 .. option:: --psy-rdoq Influence rate distortion optimized quantization by favoring higher energy in the reconstructed image. This generally improves perceived visual quality at the cost of lower quality metric scores. It only has effect when :option:`--rdoq-level` is 1 or 2. High values can be beneficial in preserving high-frequency detail. Default: 0.0 (1.0 for presets slow, slower, veryslow) **Range of values:** 0 .. 50.0 Slice decision options ====================== .. option:: --open-gop, --no-open-gop Enable open GOP, allow I-slices to be non-IDR. Default enabled .. option:: --keyint, -I Max intra period in frames. A special case of infinite-gop (single keyframe at the beginning of the stream) can be triggered with argument -1. Use 1 to force all-intra. When intra-refresh is enabled it specifies the interval between which refresh sweeps happen. Default 250 .. option:: --min-keyint, -i Minimum GOP size. Scenecuts beyond this interval are coded as IDR and start a new keyframe, while scenecuts closer together are coded as I or P. For fixed keyframe interval, set value to be equal to keyint. **Range of values:** >=0 (0: auto) .. option:: --scenecut , --no-scenecut How aggressively I-frames need to be inserted. The higher the threshold value, the more aggressive the I-frame placement. :option:`--scenecut` 0 or :option:`--no-scenecut` disables adaptive I frame placement. Default 40 .. option:: --intra-refresh Enables Periodic Intra Refresh(PIR) instead of keyframe insertion. PIR can replace keyframes by inserting a column of intra blocks in non-keyframes, that move across the video from one side to the other and thereby refresh the image but over a period of multiple frames instead of a single keyframe. .. option:: --rc-lookahead Number of frames for slice-type decision lookahead (a key determining factor for encoder latency). The longer the lookahead buffer the more accurate scenecut decisions will be, and the more effective cuTree will be at improving adaptive quant. Having a lookahead larger than the max keyframe interval is not helpful. Default 20 **Range of values:** Between the maximum consecutive bframe count (:option:`--bframes`) and 250 .. option:: --lookahead-slices <0..16> Use multiple worker threads to measure the estimated cost of each frame within the lookahead. The frame is divided into the specified number of slices, and one-thread is launched per slice. When :option:`--b-adapt` is 2, most frame cost estimates will be performed in batch mode (many cost estimates at the same time) and lookahead-slices is ignored for batched estimates; it may still be used for single cost estimations. The higher this parameter, the less accurate the frame costs will be (since context is lost across slice boundaries) which will result in less accurate B-frame and scene-cut decisions. The effect on performance can be significant especially on systems with many threads. The encoder may internally lower the number of slices or disable slicing to ensure each slice codes at least 10 16x16 rows of lowres blocks to minimize the impact on quality. For example, for 720p and 1080p videos, the number of slices is capped to 4 and 6, respectively. For resolutions lesser than 720p, slicing is auto-disabled. If slices are used in lookahead, they are logged in the list of tools as *lslices* **Values:** 0 - disabled. 1 is the same as 0. Max 16. Default: 8 for ultrafast, superfast, faster, fast, medium 4 for slow, slower disabled for veryslow, slower .. option:: --b-adapt Set the level of effort in determining B frame placement. With b-adapt 0, the GOP structure is fixed based on the values of :option:`--keyint` and :option:`--bframes`. With b-adapt 1 a light lookahead is used to choose B frame placement. With b-adapt 2 (trellis) a viterbi B path selection is performed **Values:** 0:none; 1:fast; 2:full(trellis) **default** .. option:: --bframes, -b <0..16> Maximum number of consecutive b-frames. Use :option:`--bframes` 0 to force all P/I low-latency encodes. Default 4. This parameter has a quadratic effect on the amount of memory allocated and the amount of work performed by the full trellis version of :option:`--b-adapt` lookahead. .. option:: --bframe-bias Bias towards B frames in slicetype decision. The higher the bias the more likely x265 is to use B frames. Can be any value between -90 and 100 and is clipped to that range. Default 0 .. option:: --b-pyramid, --no-b-pyramid Use B-frames as references, when possible. Default enabled Quality, rate control and rate distortion options ================================================= .. option:: --bitrate Enables single-pass ABR rate control. Specify the target bitrate in kbps. Default is 0 (CRF) **Range of values:** An integer greater than 0 .. option:: --crf <0..51.0> Quality-controlled variable bitrate. CRF is the default rate control method; it does not try to reach any particular bitrate target, instead it tries to achieve a given uniform quality and the size of the bitstream is determined by the complexity of the source video. The higher the rate factor the higher the quantization and the lower the quality. Default rate factor is 28.0. .. option:: --crf-max <0..51.0> Specify an upper limit to the rate factor which may be assigned to any given frame (ensuring a max QP). This is dangerous when CRF is used in combination with VBV as it may result in buffer underruns. Default disabled .. option:: --crf-min <0..51.0> Specify an lower limit to the rate factor which may be assigned to any given frame (ensuring a min compression factor). .. option:: --vbv-bufsize Specify the size of the VBV buffer (kbits). Enables VBV in ABR mode. In CRF mode, :option:`--vbv-maxrate` must also be specified. Default 0 (vbv disabled) .. option:: --vbv-maxrate Maximum local bitrate (kbits/sec). Will be used only if vbv-bufsize is also non-zero. Both vbv-bufsize and vbv-maxrate are required to enable VBV in CRF mode. Default 0 (disabled) Note that when VBV is enabled (with a valid :option:`--vbv-bufsize`), VBV emergency denoising is turned on. This will turn on aggressive denoising at the frame level when frame QP > QP_MAX_SPEC (51), drastically reducing bitrate and allowing ratecontrol to assign lower QPs for the following frames. The visual effect is blurring, but removes significant blocking/displacement artifacts. .. option:: --vbv-init Initial buffer occupancy. The portion of the decode buffer which must be full before the decoder will begin decoding. Determines absolute maximum frame size. May be specified as a fractional value between 0 and 1, or in kbits. In other words these two option pairs are equivalent:: --vbv-bufsize 1000 --vbv-init 900 --vbv-bufsize 1000 --vbv-init 0.9 Default 0.9 **Range of values:** fractional: 0 - 1.0, or kbits: 2 .. bufsize .. option:: --qp, -q Specify base quantization parameter for Constant QP rate control. Using this option enables Constant QP rate control. The specified QP is assigned to P slices. I and B slices are given QPs relative to P slices using param->rc.ipFactor and param->rc.pbFactor unless QP 0 is specified, in which case QP 0 is used for all slice types. Note that QP 0 does not cause lossless encoding, it only disables quantization. Default disabled (CRF) **Range of values:** an integer from 0 to 51 .. option:: --lossless, --no-lossless Enables true lossless coding by bypassing scaling, transform, quantization and in-loop filter processes. This is used for ultra-high bitrates with zero loss of quality. Reconstructed output pictures are bit-exact to the input pictures. Lossless encodes implicitly have no rate control, all rate control options are ignored. Slower presets will generally achieve better compression efficiency (and generate smaller bitstreams). Default disabled. .. option:: --aq-mode <0|1|2|3> Adaptive Quantization operating mode. Raise or lower per-block quantization based on complexity analysis of the source image. The more complex the block, the more quantization is used. This offsets the tendency of the encoder to spend too many bits on complex areas and not enough in flat areas. 0. disabled 1. AQ enabled **(default)** 2. AQ enabled with auto-variance 3. AQ enabled with auto-variance and bias to dark scenes. This is recommended for 8-bit encodes or low-bitrate 10-bit encodes, to prevent color banding/blocking. .. option:: --aq-strength Adjust the strength of the adaptive quantization offsets. Setting :option:`--aq-strength` to 0 disables AQ. At aq-modes 2 and 3, high aq-strengths will lead to high QP offsets resulting in a large difference in achieved bitrates. Default 1.0. **Range of values:** 0.0 to 3.0 .. option:: --qg-size <64|32|16|8> Enable adaptive quantization for sub-CTUs. This parameter specifies the minimum CU size at which QP can be adjusted, ie. Quantization Group size. Allowed range of values are 64, 32, 16, 8 provided this falls within the inclusive range [maxCUSize, minCUSize]. Experimental. Default: same as maxCUSize .. option:: --cutree, --no-cutree Enable the use of lookahead's lowres motion vector fields to determine the amount of reuse of each block to tune adaptive quantization factors. CU blocks which are heavily reused as motion reference for later frames are given a lower QP (more bits) while CU blocks which are quickly changed and are not referenced are given less bits. This tends to improve detail in the backgrounds of video with less detail in areas of high motion. Default enabled .. option:: --pass Enable multi-pass rate control mode. Input is encoded multiple times, storing the encoded information of each pass in a stats file from which the consecutive pass tunes the qp of each frame to improve the quality of the output. Default disabled 1. First pass, creates stats file 2. Last pass, does not overwrite stats file 3. Nth pass, overwrites stats file **Range of values:** 1 to 3 .. option:: --stats Specify file name of of the multi-pass stats file. If unspecified the encoder will use x265_2pass.log .. option:: --slow-firstpass, --no-slow-firstpass Enable first pass encode with the exact settings specified. The quality in subsequent multi-pass encodes is better (compared to first pass) when the settings match across each pass. Default enabled. When slow first pass is disabled, a **turbo** encode with the following go-fast options is used to improve performance: * :option:`--fast-intra` * :option:`--no-rect` * :option:`--no-amp` * :option:`--early-skip` * :option:`--ref` = 1 * :option:`--max-merge` = 1 * :option:`--me` = DIA * :option:`--subme` = MIN(2, :option:`--subme`) * :option:`--rd` = MIN(2, :option:`--rd`) .. option:: --strict-cbr, --no-strict-cbr Enables stricter conditions to control bitrate deviance from the target bitrate in ABR mode. Bit rate adherence is prioritised over quality. Rate tolerance is reduced to 50%. Default disabled. This option is for use-cases which require the final average bitrate to be within very strict limits of the target; preventing overshoots, while keeping the bit rate within 5% of the target setting, especially in short segment encodes. Typically, the encoder stays conservative, waiting until there is enough feedback in terms of encoded frames to control QP. strict-cbr allows the encoder to be more aggressive in hitting the target bitrate even for short segment videos. Experimental. .. option:: --cbqpoffs Offset of Cb chroma QP from the luma QP selected by rate control. This is a general way to spend more or less bits on the chroma channel. Default 0 **Range of values:** -12 to 12 .. option:: --crqpoffs Offset of Cr chroma QP from the luma QP selected by rate control. This is a general way to spend more or less bits on the chroma channel. Default 0 **Range of values:** -12 to 12 .. option:: --ipratio QP ratio factor between I and P slices. This ratio is used in all of the rate control modes. Some :option:`--tune` options may change the default value. It is not typically manually specified. Default 1.4 .. option:: --pbratio QP ratio factor between P and B slices. This ratio is used in all of the rate control modes. Some :option:`--tune` options may change the default value. It is not typically manually specified. Default 1.3 .. option:: --qcomp qComp sets the quantizer curve compression factor. It weights the frame quantizer based on the complexity of residual (measured by lookahead). Default value is 0.6. Increasing it to 1 will effectively generate CQP .. option:: --qpstep The maximum single adjustment in QP allowed to rate control. Default 4 .. option:: --qpmin sets a hard lower limit on QP allowed to ratecontrol. Default 0 .. option:: --qpmax sets a hard upper limit on QP allowed to ratecontrol. Default 69 .. option:: --rc-grain, --no-rc-grain Enables a specialised ratecontrol algorithm for film grain content. This parameter strictly minimises QP fluctuations within and across frames and removes pulsing of grain. Default disabled. Enabled when :option:'--tune' grain is applied. It is highly recommended that this option is used through the tune grain feature where a combination of param options are used to improve visual quality. .. option:: --qblur Temporally blur quants. Default 0.5 .. option:: --cplxblur temporally blur complexity. default 20 .. option:: --zones //... Tweak the bitrate of regions of the video. Each zone takes the form: ,,