* commit '6641819feedb086ebba3d2be89b8d33980f367e1':
build: Ignore generated mapfile and remove it on distclean
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '06edef3d5e072ef3c4face9ce946d2d9c36cc477':
Generate the lists of enabled protocols/bsfs from configure.
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '48362ceadeb2eb5286ae94ef7f9542d990ff7ec7':
doc: Update paths to match new examples location
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
If links don't work, fall back to using the full source path as was
previously done.
This should fix build failures with MSVC.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
During a build, a lot of *.o.-hash files are created - had not noticed
this as they are usually dumped in tmpfs on Linux. However, they
sometimes are present during a long build in the project directory, making it
annoying to commit while the project is being built.
These have been observed with Clang, -fsanitize-undefined on Arch Linux,
though other configurations may also generate such temporaries.
The solution here is on lines with the Linux kernel's .gitignore:
https://github.com/torvalds/linux/blob/master/.gitignore.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It provides the following features:
* verify correctness by comparing output to the C version.
* detect failure to save and restore clobbered callee-saved registers.
* detect 32-bit parameters being used as if they were 64-bit in x86-64
(the upper halves are not guaranteed to be zero - but in practice
they very often are, which makes those bugs hard to spot otherwise).
* easy benchmarking.
Compile by running 'make checkasm'.
Execute by running 'tests/checkasm/checkasm'.
Optional arguments are '--bench' to run benchmarks for all functions,
'--bench=<pattern>' to run benchmarks for all functions that starts with
<pattern>, and '<integer>' to seed the PRNG for reproducible results.
Contains unit tests for most h264pred functions to get started, more tests
can be added afterwards using those as a reference.
Loosely based on code from x264. Currently only supports x86 and x86-64,
but additional architectures shouldn't be too much of an obstacle to add.
Note that functions with floating point parameters or floating point
return values are not supported. Some compiler-specific features or
preprocessor hacks would likely be required to add support for that.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
* commit '1316df7aa98c4784f190d107206d0bb12c590b89':
lavu: add an API function to return the Libav version string
Conflicts:
.gitignore
Makefile
cmdutils.c
doc/APIchanges
libavutil/avutil.h
libavutil/utils.c
See: f91126643a
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This returns something like "v12_dev0-1332-g333a27c". This is much more
useful than the individual library versions, of which there are too
many, and which are very hard to map back to releases or git commits.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
The reasoning behind this addition is that various third party
applications are interested in getting some motion information out of a
video "for free" when it is available.
It was considered to export other information as well (such as the intra
information about the block, or the quantization) but the structure
might have ended up into a half full-generic, half full of codec
specific cruft. If more information is necessary, it should either be
added in the "flags" field of the AVMotionVector structure, or in
another side-data.
This commit also includes an example exporting them in a CSV stream.
* commit '706208ef47bffd525c982975d2756f7b2b220b8d':
fate: Split fate-pixdesc tests and dispatch them through Make
Conflicts:
tests/fate-run.sh
tests/ref/fate/filter-pixdesc
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It has not been properly maintained for years and there is little hope
of that changing in the future.
It appears simpler to write a new replacement from scratch than
unbreaking it.
Also the libavutil/ffversion.h will be installed.
Rationale:
* Applications might want to know FFmpeg's version besides the individual
libraries'.
* Avoids file name clash between FFmpeg's ./version.h and lib*/version.h when
a library source file includes both and is compiled on an out-of-tree build.
Fixes#1769.
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The benchmark tests the speed of the following algorithms:
MD5, SHA-1, SHA-256, SHA-512, RIPEMD-160, AES-128.
It can optionally be built to perform the same benchmark on
other crypto libraries, for comparison purposes.
The supported libraries are:
- crypto: OpenSSL's libcrypto;
- gcrypt: GnuTLS's libgcrypt;
- tomcrypt: LibTomCrypt
To enable them, use this syntax:
make VERSUS=crypto+gcrypt+tomcrypt tools/crypto_bench
They do not need to have been enabled in configure.
The gcov/lcov are a common toolchain for visualizing code coverage with
the GNU/Toolchain. The documentation and implementation of this
integration was heavily inspired from the blog entry by Mike Melanson:
http://multimedia.cx/eggs/using-lcov-with-ffmpeg/
