Since the VDPAU pixel format does not distinguish between different
VDPAU video surface chroma types, we need another way to pass this
data to the application.
Originally VDPAU in libavcodec only supported decoding to 8-bits YUV
with 4:2:0 chroma sampling. Correspondingly, applications assumed that
libavcodec expected VDP_CHROMA_TYPE_420 video surfaces for output.
However some of the new HEVC profiles proposed for addition to VDPAU
would require different depth and/or sampling:
http://lists.freedesktop.org/archives/vdpau/2014-July/000167.html
...as would lossless AVC profiles:
http://lists.freedesktop.org/archives/vdpau/2014-November/000241.html
To preserve backward binary compatibility with existing applications,
a new av_vdpau_bind_context() flag is introduced in a further change.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This can be used by the application to signal its ability to cope with
video surface of types other than 8-bits YUV 4:2:0.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This carries the pixel format that would be used if it were not for
hardware acceleration. This is equal to AVCodecContext.pix_fmt if
hardware acceleration is not in use.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This is to avoid proliferation of similar tables in following changes.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Fixes invalid writes when there are more blocks in a run than total
remaining blocks.
CC: libav-stable@libav.org
Bug-ID: CVE-2014-8548
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Fixes invalid writes with very small image heights.
CC: libav-stable@libav.org
Bug-ID: CVE-2014-8547
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The frame size must be set by the caller and each dimension must be a
multiple of 2.
CC: libav-stable@libav.org
Bug-ID: CVE-2014-8543
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
The frame size must be set by the caller and each dimension must be a
multiple of 8.
CC: libav-stable@libav.org
Bug-ID: CVE-2014-8542
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Fixes possible invalid memory access.
Based on code by Michael Niedermayer <michaelni@gmx.at>
CC: libav-stable@libav.org
Bug-ID: CVE-2014-8541
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
This is the order that the caller uses in the rest of the file. The
same operation is applied to both parameters, so this change is only
done for consistency, it doesn't change the actual behaviour.
Bug-Id: CID 732285 / CID 732286
ff_mpv_common_init sets s->context_initialized.
This fixes decoding of h261 in the cases where the demuxer
hasn't already set the frame size.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids trying to do sliced encoding, even if a slice/packet
size is requested (via the -ps option or the rtp_payload_size
field), since the encoder currently doesn't support it (or at least
our decoder can't decode it, even if the h261_encode_gob_header
function is hooked up to be called from the slicing part in
mpegvideo_enc.c).
Signed-off-by: Martin Storsjö <martin@martin.st>
Also use the same type for add_entry and check_size.
Bug-Id: CID 700699
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Vittorio Giovara <vittorio.giovarao@gmail.com>
Fix linking when only a subset of vaapi decoders is enabled.
Bug-Id: 760
CC: libav-stable@libav.org
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The input packets are always assumed to be padded and
the av_fast_ family of function takes a pointer to a pointer.
Thanks to Nicolas Dufresne <nicolas.dufresne@collabora.com> for
a similar patch.
Introduced in 7b588bb691.
Bug-Id: 766
CC: libav-stable@libav.org
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Old VDPAU drivers do not support this newly defined profile, so falling
back to Main profile is necessary for backward binary compatibility.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This avoids potential out of bounds writes, with potential future
versions of the library.
Bug-Id: CID 1254945
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
According to the DPX file format description found at
http://www.fileformat.info/format/dpx/egff.htm the ImageElement part of
the GenericImageHeader also contains an an offset to the real image data
beside the same member that can be found in the GenericFileHeader.
Libav keeps this member empty (=0) while some applications expects it to
be filled properly. FATE test updated accordingly.
Bug-Id: 742
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Don't include the function pointer table in the code segment
in arm mode.
This shouldn't have any significant performance effect. It does
end up as a few more instructions than before, for ARM, but
only at the entry to this function, not within the fft functions
themselves.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is needed to avoid banding artifacts when gammaing the picture.
Currently, if done with a video filter, the process is done on uints
instead of full float.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Keep the code as similar as possible across the codepaths to
ease spotting it for factorization.
Based on a patch from Michael Niedermayer <michaelni@gmx.at>.
The code currently set the information in at least 4 places, spare
some pointless loops.
Make the code in the loop a little uniform to make easier factorize
it out later.
'ret' can only be used without initialization if s->height <= 0, which can
only happen if avctx->height <= 0, which is validated elsewhere. Doesn't hurt
to still initialize it though.
CC: libav-stable@libav.org
Bug-Id: CID 732296
This makes sure the default behaviour of using the internal encoder
stays the same regardless if libtwolame is enabled or not (as for
any external library).
This fixes fate-lavf-mpg if libav is built with libtwolame enabled.
CC: libav-stable@libav.org
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This allows running the code on android, where 64 bit binaries with
text relocations aren't allowed to be loaded.
Signed-off-by: Martin Storsjö <martin@martin.st>
