This allows easily differentiating between both implementations within the build
system and combining the native implementation for plain RTMP with librtmp for
the RTMPE, RTMPS, RTMPT, RTMPTE protocol variants.
This will be useful to test more aggressively for failures to mark XMM
registers as clobbered in Win64 builds, and prevent regressions thereof.
Based on a patch by Ramiro Polla <ramiro.polla@gmail.com>
Allows our users to still build against a libpostproc with the old
API/ABI. Distributions can use this option to defer the soname bump.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Makes it possible to select the name/path of the tool for compiling
the non-inline assembly code.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Now that 0.8 is out we can reapply this commit. It breaks shared
avserver builds due to avserver using internal libavformat symbols,
which are now hidden, so this commit also disables avserver with
--enable-shared.
Port MPlayer tinterlace filter from MPlayer, with some ideas taken
from the FFmbc/libavfilter port, with the following main differences:
* added support for full-scale YUVJ formats
* added support for YUVA420P
* request_frame() on the filter is forced to return a frame
* some code factorization (related to the copy_picture_fields() function)
* fixed black padding values for mode 3
This reverts commit 9d6b2077b2.
This error is annoying while debugging, and if someone disables it for
convenience, it raises the odds of leaving ffmpeg unbuildable by default.
Use sched_getaffinity to determine the number of logical CPUs.
Limits the number of threads to 16 since slice threading of H.264
seems to be buggy with more than 16 threads.
Also create a plain text (.txt) file from fate.texi if the makeinfo
program is available.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When turned on, H264/CAVLC gets ~15% (CVPCMNL1_SVA_C.264) slower for
ultra-high-bitrate files, or ~2.5% (CVFI1_SVA_C.264) for lower-bitrate
files. Other codecs are affected to a lesser extent because they are
less optimized; e.g., VC-1 slows down by less than 1% (all on x86).
The patch generated 3 extra instructions (cmp, cmovae and mov) per
call to get_bits().
The performance penalty on ARM is within the error margin for most
files, up to 4% in extreme cases such as CVPCMNL1_SVA_C.264.
Based on work (for GCI) by Aneesh Dogra <lionaneesh@gmail.com>, and
inspired by patch in Chromium by Chris Evans <cevans@chromium.org>.