diff options
Diffstat (limited to 'third_party/aom/README')
| -rw-r--r-- | third_party/aom/README | 172 |
1 files changed, 0 insertions, 172 deletions
diff --git a/third_party/aom/README b/third_party/aom/README deleted file mode 100644 index 983a71343..000000000 --- a/third_party/aom/README +++ /dev/null @@ -1,172 +0,0 @@ -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. - |