vpx Multi-Format Codec SDK
README - 19 May 2010
Welcome to the WebM VP8 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 PHP[3] and Doxygen[4]. If you do not
have these packages, you must pass --disable-install-docs to the
configure script.
[1]: http://www.tortall.net/projects/yasm
[2]: http://www.cygwin.com
[3]: http://php.net
[4]: http://www.doxygen.org
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
$ ../libvpx/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:
$ ../libvpx/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:
armv5te-linux-rvct
armv5te-linux-gcc
armv5te-symbian-gcc
armv5te-wince-vs8
armv6-darwin-gcc
armv6-linux-rvct
armv6-linux-gcc
armv6-symbian-gcc
armv6-wince-vs8
iwmmxt-linux-rvct
iwmmxt-linux-gcc
iwmmxt-wince-vs8
iwmmxt2-linux-rvct
iwmmxt2-linux-gcc
iwmmxt2-wince-vs8
armv7-linux-rvct
armv7-linux-gcc
mips32-linux-gcc
ppc32-darwin8-gcc
ppc32-darwin9-gcc
ppc64-darwin8-gcc
ppc64-darwin9-gcc
ppc64-linux-gcc
x86-darwin8-gcc
x86-darwin8-icc
x86-darwin9-gcc
x86-darwin9-icc
x86-linux-gcc
x86-linux-icc
x86-solaris-gcc
x86-win32-vs7
x86-win32-vs8
x86_64-darwin9-gcc
x86_64-linux-gcc
x86_64-solaris-gcc
x86_64-win64-vs8
universal-darwin8-gcc
universal-darwin9-gcc
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- ../libvpx/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.err. This should give a good indication of what went
wrong. If not, contact us for support.
SUPPORT
This library is an open source project supported by its community. Please
please email webm-users@webmproject.org for help.
Timothy B. Terriberry
authored
The primary goal is to allow a binary to be built which supports NEON, but can fall back to non-NEON routines, since some Android devices do not have NEON, even if they are otherwise ARMv7 (e.g., Tegra). The configure-generated flags HAVE_ARMV7, etc., are used to decide which versions of each function to build, and when CONFIG_RUNTIME_CPU_DETECT is enabled, the correct version is chosen at run time. In order for this to work, the CFLAGS must be set to something appropriate (e.g., without -mfpu=neon for ARMv7, and with appropriate -march and -mcpu for even earlier configurations), or the native C code will not be able to run. The ASFLAGS must remain set for the most advanced instruction set required at build time, since the ARM assembler will refuse to emit them otherwise. I have not attempted to make any changes to configure to do this automatically. Doing so will probably require the addition of new configure options. Many of the hooks for RTCD on ARM were already there, but a lot of the code had bit-rotted, and a good deal of the ARM-specific code is not integrated into the RTCD structs at all. I did not try to resolve the latter, merely to add the minimal amount of protection around them to allow RTCD to work. Those functions that were called based on an ifdef at the calling site were expanded to check the RTCD flags at that site, but they should be added to an RTCD struct somewhere in the future. The functions invoked with global function pointers still are, but these should be moved into an RTCD struct for thread safety (I believe every platform currently supported has atomic pointer stores, but this is not guaranteed). The encoder's boolhuff functions did not even have _c and armv7 suffixes, and the correct version was resolved at link time. The token packing functions did have appropriate suffixes, but the version was selected with a define, with no associated RTCD struct. However, for both of these, the only armv7 instruction they actually used was rbit, and this was completely superfluous, so I reworked them to avoid it. The only non-ARMv4 instruction remaining in them is clz, which is ARMv5 (not even ARMv5TE is required). Considering that there are no ARM-specific configs which are not at least ARMv5TE, I did not try to detect these at runtime, and simply enable them for ARMv5 and above. Finally, the NEON register saving code was completely non-reentrant, since it saved the registers to a global, static variable. I moved the storage for this onto the stack. A single binary built with this code was tested on an ARM11 (ARMv6) and a Cortex A8 (ARMv7 w/NEON), for both the encoder and decoder, and produced identical output, while using the correct accelerated functions on each. I did not test on any earlier processors. Change-Id: I45cbd63a614f4554c3b325c45d46c0806f009eaa