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.
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.
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>
and change default type to float so that the run level
decoding functionality can be shared with wmapro
Originally committed as revision 19231 to svn://svn.ffmpeg.org/ffmpeg/trunk
Scaling (i)MDCT output has no runtime overhead and can be used to improve
performance of audio codecs. All the changes are only needed in
'ff_mdct_init' function and slow down initialization a bit.
Originally committed as revision 18855 to svn://svn.ffmpeg.org/ffmpeg/trunk
because it's being assigned as a constant. To avoid a spurious warning,
split it into two instructions, which should also make it more logical
once the FIXME is resolved.
patch by Diego 'Flameeyes' Pettenò %flameeyes A gmail P com%
Originally committed as revision 15525 to svn://svn.ffmpeg.org/ffmpeg/trunk
Patch by Ian Braithwaite ian .. braithwaite . dk
[Ffmpeg-devel] WMA decoder speedup 2007-03-22 22:56
Originally committed as revision 8526 to svn://svn.ffmpeg.org/ffmpeg/trunk