Add ability to handle multiple palettes and objects simultaneously.
Each simultaneous object is given its own AVSubtitleRect.
Note that there can be up to 64 currently valid objects, but only
2 at any one time can be "presented".
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The gcc version affected is very old and unmaintained AFAIK thus i made no
attempt to report this to the gcc developers.
The workaround is pushed as it may still affect users and does affect one
fate client
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7b0c7c9163fe3dd0081696befde28617119d2590':
arm: Detect 32 bit cpu features on ARMv8 when running on a 64 bit kernel
Merged-by: Michael Niedermayer <michaelni@gmx.at>
When running on a 64 bit kernel, /proc/cpuinfo lists different
optional features than on 32 bit kernels (because some of them
are mandatory in the 64 bit implemenations).
The kernel does list the old features properly if they are queried
via /proc/self/auxv though - however this file is not always readable
(e.g. on most android systems). The getauxval function could also
provide the same info as /proc/self/auxv even if this file isn't
readable, but this function is not always available (and thus would
need to be loaded with dlsym for compatibility with older android
versions).
The android cpufeatures library does this slightly differently,
by assuming that these are available if the "CPU architecture"
line is >= 8, see [1] for details.
It has been suggested to include the old, non-optional features in
/proc/cpuinfo as well, but that suggested patch never was merged.
See [2] for the discussion around this suggestion.
[1] https://android-review.googlesource.com/91380
[2] http://marc.info/?l=linux-arm-kernel&m=139087240101974
Signed-off-by: Martin Storsjö <martin@martin.st>
Linear interpolation goes from 63 (llvm) or 58 (gcc) to 48 (yasm)
cycles/sample on 64bit, or from 66 (llvm/gcc) to 52 (yasm) cycles/
sample on 32bit. Bon-linear goes from 43 (llvm) or 38 (gcc) to
32 (yasm) cycles/sample on 64bit, or from 46 (llvm) or 44 (gcc) to
38 (yasm) cycles/sample on 32bit (all testing on OSX 10.9.2, llvm
5.1 and gcc 4.8/9).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f134b5ec53b4cb51cb69bf0c64de87687ea72b12':
apichanges: fill in changes for lavu 51.19 and 51.20
Conflicts:
doc/APIchanges
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The commit causes minor out of array reads and was mainly intended for
future optimizations which turned out not to be meassurably faster.
Itself it was just 1 cpu cycle faster
Approved-by: jamrial
This reverts commit 057d2704e7.
* commit '5dd8c08fd5e4c04d7a08d8934f0098a8a4a35c28':
mpeg: Change ff_convert_matrix() to take an MpegEncContext parameter
Conflicts:
libavcodec/mpegvideo.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Commit fc9c857c introduced deadlock regression when processing too many inputs:
ffmpeg $(seq -f " -f lavfi -i aevalsrc=0:d=%.0f" 70) -vf concat=n=70:v=0:a=1 -f null -
Happens for different number of inputs, depending on available memory size,
overcommit settings, ulimits, etc. Easily noticeable for 32-bit builds,
that exhaust address space allocating 8-10 MB stack for each thread.
Earlier ffmpeg versions exited with unhelpful "Conversion failed!" message.
This patch fixes both problems: it frees the queue to prevent deadlock
and adds a meaningful error message if pthread_create() fails.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
