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 is necessary since the switch to floating point
input means there is no longer sufficient input data
validation.
There is a good chance that other encoders are affected
by similar issues.
This problem can be triggered by trying to encode
extremely large values and probably also with Inf and
possibly also NaNs.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Now, nellymoserenc and aacenc no longer depends on dsputil. Independent
of this patch, wmaprodec also does not depend on dsputil, so I removed
it from there also.
Also break some long lines, remove codec function placeholder comments
and add spaces in sample/pixel format lists.
Signed-off-by: Martin Storsjö <martin@martin.st>
It may have improved cross-platform stability, but wasn't the only place in
the encoder with bitexact issues. It is no longer needed because we have FATE
tests for float encoders using fuzzy comparison.
This condition cannot happen, if it can it is a bug that MUST be fixed.
And i very happily volunteer to fix it if someone reports a case to
me that fails.
This reverts commit 5d652e063b.
We need to set ms_stereo in encode_init() in order to avoid incorrectly
encoding the first frame as non-m/s while flagging it as m/s. Fixes an
uncomfortable pop in the left channel at the start of playback.
CC:libav-stable@libav.org
Currently we have an assert() that prevents the frame from being too large,
but it is more user-friendly to give an error message instead of aborting on
assert(). This condition is quite unlikely due to the minimum bit rate check
in encode_init(), but it is still worth having.
The maximum theoretical frame size is around 17000 bytes. Although in
practice it will generally be much smaller, we require a larger buffer
just to be safe.
CC: libav-stable@libav.org
ff_wma_init() allows up to 50kHz, but this generates an exponent band
size table that requires 65 bands. The code assumes 25 bands in many
places, and using sample rates higher than 48kHz will lead to buffer
overwrites.
CC:libav-stable@libav.org
This is near the theoretical limit for wma frame size and is the most that
our decoder can handle. Allowing higher bit rates will just end up padding
each frame with empty bytes.
Fixes invalid writes for avconv when using very high bit rates.
CC:libav-stable@libav.org
This removes the rather pointless wrappers (one not even inline)
for calling the fft_calc and related function pointers.
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>
(cherry picked from commit d36beb3f69)
Michael Niedermayer
Anton Khirnov
Gabriel Dume
Diego Biurrun
Reimar Döffinger
James Zern
Justin Ruggles
Ronald S. Bultje
Piotr Bandurski
Paul B Mahol
Martin Storsjö
Tomas Härdin
Mans Rullgard
Diego Elio Pettenò
Stefano Sabatini