| README - 9 March 2017 | 
 |  | 
 | *************************** | 
 | DEPRECATED -- SEE README.md | 
 | *************************** | 
 |  | 
 | Welcome to the AV1 Codec SDK! | 
 |  | 
 | COMPILING THE APPLICATIONS/LIBRARIES: | 
 |   The build system used is similar to autotools. Building generally consists of | 
 |   "configuring" with your desired build options, then using GNU make to build | 
 |   the application. | 
 |  | 
 |   1. Prerequisites | 
 |  | 
 |     * All x86 targets require the Yasm[1] assembler be installed. | 
 |     * All Windows builds require that Cygwin[2] be installed. | 
 |     * Building the documentation requires Doxygen[3]. If you do not | 
 |       have this package, the install-docs option will be disabled. | 
 |     * Downloading the data for the unit tests requires curl[4] and sha1sum. | 
 |       sha1sum is provided via the GNU coreutils, installed by default on | 
 |       many *nix platforms, as well as MinGW and Cygwin. If coreutils is not | 
 |       available, a compatible version of sha1sum can be built from | 
 |       source[5]. These requirements are optional if not running the unit | 
 |       tests. | 
 |  | 
 |     [1]: http://www.tortall.net/projects/yasm | 
 |     [2]: http://www.cygwin.com | 
 |     [3]: http://www.doxygen.org | 
 |     [4]: http://curl.haxx.se | 
 |     [5]: http://www.microbrew.org/tools/md5sha1sum/ | 
 |  | 
 |   2. Out-of-tree builds | 
 |   Out of tree builds are a supported method of building the application. For | 
 |   an out of tree build, the source tree is kept separate from the object | 
 |   files produced during compilation. For instance: | 
 |  | 
 |     $ mkdir build | 
 |     $ cd build | 
 |     $ ../libaom/configure <options> | 
 |     $ make | 
 |  | 
 |   3. Configuration options | 
 |   The 'configure' script supports a number of options. The --help option can be | 
 |   used to get a list of supported options: | 
 |     $ ../libaom/configure --help | 
 |  | 
 |   4. Cross development | 
 |   For cross development, the most notable option is the --target option. The | 
 |   most up-to-date list of supported targets can be found at the bottom of the | 
 |   --help output of the configure script. As of this writing, the list of | 
 |   available targets is: | 
 |  | 
 |     arm64-darwin-gcc | 
 |     armv7-android-gcc | 
 |     armv7-darwin-gcc | 
 |     armv7-linux-rvct | 
 |     armv7-linux-gcc | 
 |     armv7-none-rvct | 
 |     armv7-win32-vs12 | 
 |     armv7-win32-vs14 | 
 |     armv7-win32-vs15 | 
 |     armv7s-darwin-gcc | 
 |     mips32-linux-gcc | 
 |     mips64-linux-gcc | 
 |     sparc-solaris-gcc | 
 |     x86-android-gcc | 
 |     x86-darwin8-gcc | 
 |     x86-darwin8-icc | 
 |     x86-darwin9-gcc | 
 |     x86-darwin9-icc | 
 |     x86-darwin10-gcc | 
 |     x86-darwin11-gcc | 
 |     x86-darwin12-gcc | 
 |     x86-darwin13-gcc | 
 |     x86-darwin14-gcc | 
 |     x86-darwin15-gcc | 
 |     x86-darwin16-gcc | 
 |     x86-iphonesimulator-gcc | 
 |     x86-linux-gcc | 
 |     x86-linux-icc | 
 |     x86-os2-gcc | 
 |     x86-solaris-gcc | 
 |     x86-win32-gcc | 
 |     x86-win32-vs12 | 
 |     x86-win32-vs14 | 
 |     x86-win32-vs15 | 
 |     x86_64-android-gcc | 
 |     x86_64-darwin9-gcc | 
 |     x86_64-darwin10-gcc | 
 |     x86_64-darwin11-gcc | 
 |     x86_64-darwin12-gcc | 
 |     x86_64-darwin13-gcc | 
 |     x86_64-darwin14-gcc | 
 |     x86_64-darwin15-gcc | 
 |     x86_64-darwin16-gcc | 
 |     x86_64-iphonesimulator-gcc | 
 |     x86_64-linux-gcc | 
 |     x86_64-linux-icc | 
 |     x86_64-solaris-gcc | 
 |     x86_64-win64-gcc | 
 |     x86_64-win64-vs12 | 
 |     x86_64-win64-vs14 | 
 |     x86_64-win64-vs15 | 
 |     generic-gnu | 
 |  | 
 |   The generic-gnu target, in conjunction with the CROSS environment variable, | 
 |   can be used to cross compile architectures that aren't explicitly listed, if | 
 |   the toolchain is a cross GNU (gcc/binutils) toolchain. Other POSIX toolchains | 
 |   will likely work as well. For instance, to build using the mipsel-linux-uclibc | 
 |   toolchain, the following command could be used (note, POSIX SH syntax, adapt | 
 |   to your shell as necessary): | 
 |  | 
 |     $ CROSS=mipsel-linux-uclibc- ../libaom/configure | 
 |  | 
 |   In addition, the executables to be invoked can be overridden by specifying the | 
 |   environment variables: CC, AR, LD, AS, STRIP, NM. Additional flags can be | 
 |   passed to these executables with CFLAGS, LDFLAGS, and ASFLAGS. | 
 |  | 
 |   5. Configuration errors | 
 |   If the configuration step fails, the first step is to look in the error log. | 
 |   This defaults to config.log. This should give a good indication of what went | 
 |   wrong. If not, contact us for support. | 
 |  | 
 | AV1 TEST VECTORS: | 
 |   The test vectors can be downloaded and verified using the build system after | 
 |   running configure. To specify an alternate directory the | 
 |   LIBAOM_TEST_DATA_PATH environment variable can be used. | 
 |  | 
 |   $ ./configure --enable-unit-tests | 
 |   $ LIBAOM_TEST_DATA_PATH=../-test-data make testdata | 
 |  | 
 | UNIT TESTS: | 
 |   The unit tests (consisting mainly of the test_libaom binary) can be run using | 
 |   make. This will download the test data if necessary. | 
 |  | 
 |   $ ../libaom/configure --enable-unit-tests | 
 |   $ make test | 
 |  | 
 |   Test may be run in parallel using make -j which supports up to 10 shards by | 
 |   default. | 
 |   $ make -j10 test | 
 |  | 
 |   If you have additional cores you can scale the tests to match: | 
 |   $ shards=$(nproc); \ | 
 |     make -j$shards test \ | 
 |     NUM_SHARDS=$shards SHARDS="$(seq -s' ' 0 $(( shards - 1 )))" \ | 
 |     && echo "success" | 
 |  | 
 |   The GTEST_FILTER environment variable (equivalent to --gtest_filter) can be | 
 |   used to control which tests are run while sharding: | 
 |   $ GTEST_FILTER='SSE2*' make -j10 test | 
 |  | 
 | CODE STYLE: | 
 |   The coding style used by this project is enforced with clang-format using the | 
 |   configuration contained in the .clang-format file in the root of the | 
 |   repository. | 
 |  | 
 |   Before pushing changes for review you can format your code with: | 
 |   # Apply clang-format to modified .c, .h and .cc files | 
 |   $ clang-format -i --style=file \ | 
 |     $(git diff --name-only --diff-filter=ACMR '*.[hc]' '*.cc') | 
 |  | 
 |   Check the .clang-format file for the version used to generate it if there is | 
 |   any difference between your local formatting and the review system. | 
 |  | 
 |   See also: http://clang.llvm.org/docs/ClangFormat.html | 
 |  | 
 | SUPPORT | 
 |   This library is an open source project supported by its community. Please | 
 |   please email webm-discuss@webmproject.org for help. | 
 |  |