README 5.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166
  1. README - 15 July 2019
  2. Welcome to the WebM VP8/VP9 Codec SDK!
  3. COMPILING THE APPLICATIONS/LIBRARIES:
  4. The build system used is similar to autotools. Building generally consists of
  5. "configuring" with your desired build options, then using GNU make to build
  6. the application.
  7. 1. Prerequisites
  8. * All x86 targets require the Yasm[1] assembler be installed[2].
  9. * All Windows builds require that Cygwin[3] be installed.
  10. * Building the documentation requires Doxygen[4]. If you do not
  11. have this package, the install-docs option will be disabled.
  12. * Downloading the data for the unit tests requires curl[5] and sha1sum.
  13. sha1sum is provided via the GNU coreutils, installed by default on
  14. many *nix platforms, as well as MinGW and Cygwin. If coreutils is not
  15. available, a compatible version of sha1sum can be built from
  16. source[6]. These requirements are optional if not running the unit
  17. tests.
  18. [1]: http://www.tortall.net/projects/yasm
  19. [2]: For Visual Studio the base yasm binary (not vsyasm) should be in the
  20. PATH for Visual Studio. For VS2017 it is sufficient to rename
  21. yasm-<version>-<arch>.exe to yasm.exe and place it in:
  22. Program Files (x86)/Microsoft Visual Studio/2017/<level>/Common7/Tools/
  23. [3]: http://www.cygwin.com
  24. [4]: http://www.doxygen.org
  25. [5]: http://curl.haxx.se
  26. [6]: http://www.microbrew.org/tools/md5sha1sum/
  27. 2. Out-of-tree builds
  28. Out of tree builds are a supported method of building the application. For
  29. an out of tree build, the source tree is kept separate from the object
  30. files produced during compilation. For instance:
  31. $ mkdir build
  32. $ cd build
  33. $ ../libvpx/configure <options>
  34. $ make
  35. 3. Configuration options
  36. The 'configure' script supports a number of options. The --help option can be
  37. used to get a list of supported options:
  38. $ ../libvpx/configure --help
  39. 4. Compiler analyzers
  40. Compilers have added sanitizers which instrument binaries with information
  41. about address calculation, memory usage, threading, undefined behavior, and
  42. other common errors. To simplify building libvpx with some of these features
  43. use tools/set_analyzer_env.sh before running configure. It will set the
  44. compiler and necessary flags for building as well as environment variables
  45. read by the analyzer when testing the binaries.
  46. $ source ../libvpx/tools/set_analyzer_env.sh address
  47. 5. Cross development
  48. For cross development, the most notable option is the --target option. The
  49. most up-to-date list of supported targets can be found at the bottom of the
  50. --help output of the configure script. As of this writing, the list of
  51. available targets is:
  52. arm64-android-gcc
  53. arm64-darwin-gcc
  54. arm64-linux-gcc
  55. arm64-win64-gcc
  56. arm64-win64-vs15
  57. armv7-android-gcc
  58. armv7-darwin-gcc
  59. armv7-linux-rvct
  60. armv7-linux-gcc
  61. armv7-none-rvct
  62. armv7-win32-gcc
  63. armv7-win32-vs14
  64. armv7-win32-vs15
  65. armv7s-darwin-gcc
  66. armv8-linux-gcc
  67. mips32-linux-gcc
  68. mips64-linux-gcc
  69. ppc64le-linux-gcc
  70. sparc-solaris-gcc
  71. x86-android-gcc
  72. x86-darwin8-gcc
  73. x86-darwin8-icc
  74. x86-darwin9-gcc
  75. x86-darwin9-icc
  76. x86-darwin10-gcc
  77. x86-darwin11-gcc
  78. x86-darwin12-gcc
  79. x86-darwin13-gcc
  80. x86-darwin14-gcc
  81. x86-darwin15-gcc
  82. x86-darwin16-gcc
  83. x86-darwin17-gcc
  84. x86-iphonesimulator-gcc
  85. x86-linux-gcc
  86. x86-linux-icc
  87. x86-os2-gcc
  88. x86-solaris-gcc
  89. x86-win32-gcc
  90. x86-win32-vs14
  91. x86-win32-vs15
  92. x86_64-android-gcc
  93. x86_64-darwin9-gcc
  94. x86_64-darwin10-gcc
  95. x86_64-darwin11-gcc
  96. x86_64-darwin12-gcc
  97. x86_64-darwin13-gcc
  98. x86_64-darwin14-gcc
  99. x86_64-darwin15-gcc
  100. x86_64-darwin16-gcc
  101. x86_64-darwin17-gcc
  102. x86_64-iphonesimulator-gcc
  103. x86_64-linux-gcc
  104. x86_64-linux-icc
  105. x86_64-solaris-gcc
  106. x86_64-win64-gcc
  107. x86_64-win64-vs14
  108. x86_64-win64-vs15
  109. generic-gnu
  110. The generic-gnu target, in conjunction with the CROSS environment variable,
  111. can be used to cross compile architectures that aren't explicitly listed, if
  112. the toolchain is a cross GNU (gcc/binutils) toolchain. Other POSIX toolchains
  113. will likely work as well. For instance, to build using the mipsel-linux-uclibc
  114. toolchain, the following command could be used (note, POSIX SH syntax, adapt
  115. to your shell as necessary):
  116. $ CROSS=mipsel-linux-uclibc- ../libvpx/configure
  117. In addition, the executables to be invoked can be overridden by specifying the
  118. environment variables: CC, AR, LD, AS, STRIP, NM. Additional flags can be
  119. passed to these executables with CFLAGS, LDFLAGS, and ASFLAGS.
  120. 6. Configuration errors
  121. If the configuration step fails, the first step is to look in the error log.
  122. This defaults to config.log. This should give a good indication of what went
  123. wrong. If not, contact us for support.
  124. VP8/VP9 TEST VECTORS:
  125. The test vectors can be downloaded and verified using the build system after
  126. running configure. To specify an alternate directory the
  127. LIBVPX_TEST_DATA_PATH environment variable can be used.
  128. $ ./configure --enable-unit-tests
  129. $ LIBVPX_TEST_DATA_PATH=../libvpx-test-data make testdata
  130. CODE STYLE:
  131. The coding style used by this project is enforced with clang-format using the
  132. configuration contained in the .clang-format file in the root of the
  133. repository.
  134. Before pushing changes for review you can format your code with:
  135. # Apply clang-format to modified .c, .h and .cc files
  136. $ clang-format -i --style=file \
  137. $(git diff --name-only --diff-filter=ACMR '*.[hc]' '*.cc')
  138. Check the .clang-format file for the version used to generate it if there is
  139. any difference between your local formatting and the review system.
  140. See also: http://clang.llvm.org/docs/ClangFormat.html
  141. SUPPORT
  142. This library is an open source project supported by its community. Please
  143. email webm-discuss@webmproject.org for help.