* qatar/master:
avio: add more documentation for AVIOContext.
Parse sprite data for WMVP and WVP2, and decode sprites for the latter
Replace outdated info on the FAQ
Redefine sameq
pad: fix example explanation
gradfun: add notice from the MPlayer manual
eval: add support for trunc, ceil, and floor functions
documentation: add setdar and setsar description to filters.texi
avio: document some members of AVIOContext.
avio: document avio_close().
avio: cosmetics, vertically align comments.
avio: cosmetics, group the reading functions.
avio: cosmetics, merge all the FF_API_OLD_AVIO blocks.
avio: cosmetics, move AVIOContext to start of the file.
avio: update file header.
os: fix OpenBSD/PowerPC compilation
pixfmt: add PIX_FMT_BGR48LE and PIX_FMT_BGR48BE
oggdec: fix demuxing chained audio streams
fix typo
Conflicts:
doc/filters.texi
libavformat/avio.h
libavutil/pixfmt.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Mostly useful for the audio-filters branch, to make more apparent the
distinction between configure_audio_filters() and
configure_video_filters().
Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>
This patch lets e.g. dsputil_init chose dsp functions with respect to
the bit depth to decode. The naming scheme of bit depth dependent
functions is <base name>_<bit depth>[_<prefix>] (i.e. the old
clear_blocks_c is now named clear_blocks_8_c).
Note: Some of the functions for high bit depth is not dependent on the
bit depth, but only on the pixel size. This leaves some room for
optimizing binary size.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In high bit depth, the QP values may now be up to (51 + 6*(bit_depth-8)).
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In high bit depth the pixels will not be stored in uint8_t like in the
normal case, but in uint16_t. The pixel size is thus 1 in normal bit
depth and 2 in high bit depth.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The functions moved are used when decoding h264.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Unfortunately the output buffer size check assumes that the
input buffer is never over-consumed, thus this actually
also allowed to write outside the output buffer if "lucky".
FAQ could use some work. This updates a few little details.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
I think the documentation of sameq is causing confusion and misuse of
this option.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
"row" and "column" term positions in the explanation were inverted.
Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When attempting to re-enable the AltiVec support it was noticed
that we need to undefine _POSIX_C_SOURCE to appease the headers
for ff_get_cpu_flags_ppc() to be able to compile.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
AS libavcodec/arm/ac3dsp_armv6.o
ffmpeg-src/libavcodec/arm/ac3dsp_armv6.S: Assembler messages:
ffmpeg-src/libavcodec/arm/ac3dsp_armv6.S:40: Error: selected processor
does not support `movw r8,#0x1fe0'
make[1]: *** [libavcodec/arm/ac3dsp_armv6.o] Error 1
MOVW is ARMv7 way to load constant:
* movw, or move wide, will move a 16-bit constant into a register,
implicitly zeroing the top 16 bits of the target register.
* movt, or move top, will move a 16-bit constant into the top half
of a given register without altering the bottom 16 bits
To load 32 bit constant, movw lower16; movt upper16; is better than
ldr if available, because:
While this approach takes two instructions, it does not require any
extra space to store the constant so both the movw/movt method and the
ldr method will end up using the same amount of memory. Memory
bandwidth is precious in and the movw/movt approach avoids an extra
read on the data side, not to mention the read could have missed the
cache.
But here it is armv6 optimization, so that we have to use ldr.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
