This improves motion estimation and avoids using uninitialized data
for resolutions that aren't a multiple of 16.
Prior to d2a25c40, the edges used to be initialized so that encoding
was deterministic, but after that commit it started using uninitialized
data (for non multiple of 16 resolutions).
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
The 1.3 release branch of OpenH264 (as well as the master branch)
have been updated so that GCC no longer warns about this variable
as being unused.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes out of array reads and/or infinite loops.
30 is the maximum number of bits that can be read into
coeff_abs below.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Martin Storsjö <martin@martin.st>
Move the lavc/imgconvert functions and rename them as follows:
avpicture_get_size -> av_image_get_buffer_size()
avpicture_fill -> av_image_fill_arrays()
avpicture_layout -> av_image_copy_to_buffer()
The new functions have an align parameter, which allows to define the
linesize alignment assumed in the buffer (which is set or read).
The names of the functions are consistent with the lavu/samples API
(av_samples_get_buffer_size(), av_samples_fill_arrays()).
A redundant check has been dropped from av_image_fill_arrays().
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The latest version added support for a new option for enabling
a signal level limiter, which adds some extra delay. In fdk-aac, this
is enabled by default, but disable it by default here since we'd rather
have zero-delay decoding.
Signed-off-by: Martin Storsjö <martin@martin.st>
These have a DXSA tag and contain alpha in addition to
color values for palette.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Compared to existing, common opensource H264 encoders, this can be
useful since it has got a different license (BSD instead of GPL).
Performance- and qualitywise it is comparable to x264 in ultrafast
mode.
Hooking it up as an encoder in libavcodec also simplifies comparing
it against other common encoders.
This requires OpenH264 1.3 or newer. Since the OpenH264 API and ABI
changes frequently, only releases are supported.
To take advantage of the OpenH264 patent offer, the OpenH264 library
must not be redistributed, but downloaded at runtime at the end-user's
system.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is the order that the caller uses in the rest of the file.
Variables are modified to reflect the order above too and their
initialization is merged with their declarationt. No behavioral
change.
Bug-Id: CID 732286
On some video samples, VDA silently fails to decode frames and returns
kVDADecoderNoErr. Error out in these cases to avoid producing AVFrames with
empty planes.
Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
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>
Use av_mallocz_array instead of iterating and check the returned memory.
Check returned memory and cleanly exit in case of error during the loop.
Avoid a null pointer dereference for invalid data.
CC: libav-stable@libav.org
Bug-Id: CID 29575
vorbis_parser.o is built unconditionally since 5e80fb7ff, and the
unconditionally built parts of it depend on xiph.o.
This fixes builds with --disable-everything.
Signed-off-by: Martin Storsjö <martin@martin.st>
The latest fdk-aac code drop (from android 5.0) changed the channel
layout enums (changing the value of existing enum constants), and
renamed the option for downmixing.
The failsafe comparison between ctype and FF_ARRAY_ELEMS(channel_counts)
can trigger warnings (-Wtautological-constant-out-of-range-compare)
when building with the old FDK AAC releases, where it can't be
out of range with the enum values used there.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
The only parameters needed by the demuxers are the sample rate and sample
count, which can be trivially extracted manually, without resorting to
an avpriv function.
Currently, the API takes an external AVCodecContext, which is used only
for extradata and logging. This change will allow to it to work without
an AVCodecContext in the following commits.
The application will destroy the underlying hardware handles when
get_format() gets called again. Also this ensures the
deinitialization takes place if the get_format callback returns an
error.
Regression from 1c80c9d7ef.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The H.264 Constrained Baseline Profile (CBP) is a subset of both the
Main Profile and the Baseline Profile. In principles, a hardware
decoder that supports either of those can decode CBP content. As it
happens, Main is supported by all VDPAU drivers, and Baseline is not.
So favor map CBP to MP for now. Hopefully in the future libvdpau will
offer an explicit choice for CBP.
This fixes bug 757.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Whenever av_gettime() is used to measure relative period of time,
av_gettime_relative() is prefered as it guarantee monotonic time
on supported platforms.
Signed-off-by: Martin Storsjö <martin@martin.st>
Currently, this option is accessed through AVCodecContext.mb_threshold,
which originally controlled reusing MB data when transcoding mpeg to
mpeg. Since the libvpx meaning is completely different from the original
mpegvideo meaning, it is better to use a separate private option for
this.
For streams which contain DRC metadata, the FDK decoder is able to
control rendering of the decoded output. The rendering parameters
are detailed in fdk_aac_dec_options [].
The default behavior is left up to the decoder.
Signed-off-by: Martin Storsjö <martin@martin.st>
The FDK decoder is capable of producing mono and stereo downmix from
multichannel streams. These streams may contain metadata that control
the downmix process. The decoder requires an Ancillary Buffer in order to
correctly apply downmix in streams containing downmix Metadata. The
decoder does not have an API interface to inform of the presence of
Metadata in the stream, and therefore the Ancillary Buffer is always
allocated whenever a downmix is requested.
When downmixing multichannel streams, the decoder requires the output
buffer in aacDecoder_DecodeFrame call to be of fixed size in order to
hold the actual number of channels contained in the stream. For example,
for a 5.1ch to stereo downmix, the decoder requires that the output buffer
is allocated for 6 channels, regardless of the fact that the output is in
fact two channels.
Due to this requirement, the output buffer is allocated for the maximum
output buffer size in case a downmix is requested (and also during
decoder init). When a downmix is requested, the buffer used for output
during init will also be used for the entire duration the decoder is open.
Otherwise, the initial decoder output buffer is freed and the decoder
decodes straight into the output AVFrame.
Signed-off-by: Martin Storsjö <martin@martin.st>
When decoding, this field holds the inverse of the framerate that can be
written in the headers for some codecs. Using a field called 'time_base'
for this is very misleading, as there are no timestamps associated with
it. Furthermore, this field is used for a very different purpose during
encoding.
Add a new field, called 'framerate', to replace the use of time_base for
decoding.
Decoding acceleration may work even if the codec level is higher than
the stated limit of the VDPAU driver. Or the problem may be considered
acceptable by the user. This flag allows skipping the codec level
capability checks and proceed with decoding.
Applications should obviously not set this flag by default, but only if
the user explicitly requested this behavior (and presumably knows how
to turn it back off if it fails).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Currently, the amount of padding inserted at the beginning by some audio
encoders, is exported through AVCodecContext.delay. However
- the term 'delay' is heavily overloaded and can have multiple different
meanings even in the case of audio encoding.
- this field has entirely different meanings, depending on whether the
codec context is used for encoding or decoding (and has yet another
different meaning for video), preventing generic handling of the codec
context.
Therefore, add a new field -- AVCodecContext.initial_padding. It could
conceivably be used for decoding as well at a later point.
This makes the addition of arch optimized functions easier.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The register function now specifies that the user callback should
leave things in the same state that it found them on failure but
that failure to destroy is ignored by the library. The register
function is now explicit about its behavior on failure
(it unregisters the previous callback and destroys all mutex).
Signed-off-by: Manfred Georg <mgeorg@google.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This function provides an explicit VDPAU device and VDPAU driver to
libavcodec, so that the application is relieved from codec specifics
and VdpDevice life cycle management.
A stub flags parameter is added for future extension. For instance, it
could be used to ignore codec level capabilities (if someone feels
dangerous).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This is necessary to recreate the decoder with the correct parameters,
as not all codecs invoke get_format() in this case.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Using the not so new init and uninit callbacks, avcodec can now take
care of creating and destroying the VDPAU decoder instance.
The application is still responsible for creating the VDPAU device
and allocating video surfaces - this is necessary to keep video
surfaces on the GPU all the way to the output. But the application
will no longer needs to care about any codec-specific aspects.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This is similar to what is done in libx264.c
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
