Up until now, ff_alloc_packet2() has a min_size parameter:
It is supposed to be a lower bound on the final size of the packet
to allocate. If it is not too far from the upper bound (namely,
if it is at least half the upper bound), then ff_alloc_packet2()
already allocates the final, already refcounted packet; if it is
not, then the packet is not refcounted and its data only points to
a buffer owned by the AVCodecContext (in this case, the packet will
be made refcounted in encode_simple_internal() in libavcodec/encode.c).
The goal of this was to avoid data copies and intermediate buffers
if one has a precise lower bound.
Yet those encoders for which precise lower bounds exist have recently
been switched to ff_get_encode_buffer() (which automatically allocates
final buffers), leaving only two encoders to actually set the min_size
to something else than zero (namely aliaspixenc and hapenc). Both of
these encoders use a very low lower bound that is not helpful in any
nontrivial case.
This commit therefore removes the min_size parameter as well as the
codepath in ff_alloc_packet2() for the allocation of final buffers.
Furthermore, the function has been renamed to ff_alloc_packet() and
moved to encode.h alongside ff_get_encode_buffer().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVCodecContext.extradata is freed generically by libavcodec for
encoders, so it is unnecessary for an encoder to do it on its own.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that the AVCodec.next pointer has now been removed, most of the
AVCodecs are not modified at all any more and can therefore be made
const (as this patch does); the only exceptions are the very few codecs
for external libraries that have a init_static_data callback.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
MSVC expands the preprocessor directives differently, making the
version check fail in the previous form.
Clang can warn about this with -Wexpansion-to-defined (not currently
enabled by default):
warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined]
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'ffb9b7a6bab6c6bfd3dd9a7c32e3724209824999':
libfdk-aac: Consistently use a proper version check macro for detecting features
Merged-by: James Almer <jamrial@gmail.com>
The previous version checks checked explicitly for the version
where the version define was added to the installed headers,
making an "#ifdef AACDECODER_LIB_VL0" enough. Now that we have
a need for more diverse version checks than this, convert all checks
to such checks.
Signed-off-by: Martin Storsjö <martin@martin.st>
When flushing the encoder, we now need to provide non-null buffer
parameters for everything, even if they are unused.
The encoderDelay parameter has been replaced by two, nDelay and
nDelayCore.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'b93026777aada7742583d8c5ab079e9f4dfe9a5d':
libfdk-aac: Use enum names instead of literal numbers for the output format
Merged-by: James Almer <jamrial@gmail.com>
Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.
Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.
AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
implementations in case the hardware is not capable.
Based on a patch by Philip Langdale <philipl@overt.org>.
Merges Libav commit 47687a2f8a.
Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.
Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.
AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
implementations in case the hardware is not capable.
Based on a patch by Philip Langdale <philipl@overt.org>.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit '97cfe1d8bd1968143e2ba9aa46ebe9504a835e24':
Convert all AVClass struct declarations to designated initializers.
Merged-by: James Almer <jamrial@gmail.com>
This parameter can be used to inform the allocation code about how much
downsizing might occur, and can be used to optimize how to allocate the
packet
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '2df0c32ea12ddfa72ba88309812bfb13b674130f':
lavc: use a separate field for exporting audio encoder padding
Conflicts:
libavcodec/audio_frame_queue.c
libavcodec/avcodec.h
libavcodec/libvorbisenc.c
libavcodec/utils.c
libavcodec/version.h
libavcodec/wmaenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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.
* commit '2f7065190ad48744014a02288799d03adfa613e0':
libfdk-aac: Relicense the library wrappers to the ISC license
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This reduces the number of different licenses used within libav,
and is preferrable since it has less ambiguous wordings than
the BSD license with respect to the duties of the user of the code.
Fraunhofer have now indicated that they're allowed to contribute
code under this license as well.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '3828eb8519c1530392ab8820b1aa784602128afc':
libfdk-aac: Relicense the library wrappers to 2-clause BSD
Conflicts:
libavcodec/libfdk-aacdec.c
libavcodec/libfdk-aacenc.c
<Daemon404> michaelni, fyi, for the fdk relicensing, wbs also contact all the ffmpeg-only contributers
<Daemon404> so it should be fine to merge.
Thanks-to: Martin Storsjö <martin@martin.st>
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This should make it possible for Fraunhofer to contribute to these
wrappers - they didn't want to contribute to code under LGPL2.1 with
the "or any later version" clause (which allowed using the code
under the LGPL3 license).
Signed-off-by: Martin Storsjö <martin@martin.st>
7.1(wide) and 7.1(wide-side) channel layouts are supported in
fdk-aac since the 0.1.3 release.
The earlier versions of fdk-aac didn't include any library
version defines in the public headers, thus checking for
the AACENCODER_LIB_VL0 define is enough to know that we're
building against a new enough version of fdk-aac.
This change includes contributions by Tim Walker,
Michael Niedermayer and Timothy Gu.
Signed-off-by: Martin Storsjö <martin@martin.st>
Enable compilation on machines with an old libfdk-aac.
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This was suggested by Rodeo on IRC
<Rodeo> for consistency with the rest, MODE_7_1_FRONT_CENTER would be AV_CH_LAYOUT_7POINT1_WIDE_BACK (since LS+RS is mapped to back channels in other modes)
Reviewed-by: Jean First <jeanfirst@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This was suggested by Rodeo on IRC
<Rodeo> sorry, I meant MODE_7_1_REAR_SURROUND would probably be AV_CH_LAYOUT_7POINT1
Reviewed-by: Jean First <jeanfirst@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
7.1(wide) and 7.1(wide-side) channel layouts are supported in fdk_aac since october 2013 (commit fa3eba1644)
Signed-off-by: Jean First <jeanfirst@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '0f24a3ca999a702f83af9307f9f47b6fdeb546a5':
lavc: remove disabled FF_API_OLD_ENCODE_VIDEO cruft
lavc: remove disabled FF_API_OLD_ENCODE_AUDIO cruft
lavc: remove disabled FF_API_OLD_DECODE_AUDIO cruft
Conflicts:
libavcodec/flacenc.c
libavcodec/libgsm.c
libavcodec/utils.c
libavcodec/version.h
The compatibility wrapers are left as they likely sre still
in wide use. They will be removed when they break or otherwise
cause work without an volunteer being available.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Andreas Rheinhardt