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>

Almost all the places from which this function is called already check
the header manually and in the two that don't (the mp3 muxer) the check
should not cause any problems.

Express bitfields more simply.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Convert doxygen to multiline and express bitfields more simply.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

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.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

As indicated in the function documentation, the header MUST be
checked prior to calling it because no consistency check is done
there.

CC:libav-stable@libav.org

Signed-off-by: Martin Storsjö <martin@martin.st>

CC:libav-stable@libav.org

Signed-off-by: Martin Storsjö <martin@martin.st>

Also reorder some other #include when applicable.

The LAME API documentation for the required buffer size refers to the size for
a single encode call. However, we store multiple frames in the same output
buffer but only read 1 frame at a time out of it. As a result, the buffer size
given in lame_encode_buffer() is actually smaller than what it should be.
Since we do not know how many frames it will end up buffering, it is best to
just reallocate if needed.

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Also, only set bit rate for CBR.

also remove unneeded commented-out full frame data debugging

We now require at least libmp3lame 3.98.3.
lame_encode_buffer_interleaved() still doesn't work for mono, but it does not
"die"; it just expects a stereo interleaved buffer.

it is already set in avcodec_alloc_frame()

Signed-off-by: Diego Biurrun <diego@biurrun.de>

FF_API_LAME_GLOBAL_OPTIONS => FF_API_LAME_GLOBAL_OPTS

Thanks to Clément Bœsch for spotting.

Deprecate CODEC_FLAG2_BIT_RESERVOIR

It's more readable and less prone to breakage.

Fixes compilation with mp3lame enabled.

Signed-off-by: Mans Rullgard <mans@mansr.com>

None of these symbols should be accessed directly, so declare them as
hidden.

Signed-off-by: Mans Rullgard <mans@mansr.com>

SampleFormat with AVSampleFormat.

Originally committed as revision 25730 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Thierry Foucu, tfoucu gmail

Originally committed as revision 25650 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 25129 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by James Darnley, james D darnley A gmail

Originally committed as revision 25128 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22944 to svn://svn.ffmpeg.org/ffmpeg/trunk