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.
Bitrate calculation is off since the bluray spec always specifies
an even number of coded channels. This was honored in the decoder,
but not for bitrate calculation.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This way avserver only depends on the data structures of the ffm
demuxer, which it already does, and not also on private functions
being exported by the library.
Signed-off-by: Mans Rullgard <mans@mansr.com>
For a sample size of 32 bits, the shift would overflow producing
undefined results. Incidentally, in the only test currently using
32-bit samples, the output matches the reference exactly on most
systems meaning the bad 'max' value is never used.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Add a configure function to pull in a compat object and set up
redirects in one operation. This avoids duplicating conditions
across configure and makefiles.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Some systems, e.g. Minix, have sys/mman.h defining MAP_ANONYMOUS without
providing (working) mmap and friends. The mmx filter generation code
checks only for MAP_ANONYMOUS, not for availability of mmap itself which
leads to build errors on aforementioned systems.
This changes the conditional compilation to use mmap only if all the
required functions are available.
Signed-off-by: Mans Rullgard <mans@mansr.com>
The glibc definitions of INFINITY and NAN do not work with the
tms470 compiler, nor do our usual fallbacks.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Apply flags to work around glibc quirks only if glibc is detected,
and add a few more such flags.
Do not mess with as/ld settings in probe_cc. This is not the
proper place.
Signed-off-by: Mans Rullgard <mans@mansr.com>
We cannot clip to INT_MAX because that value cannot be exactly
represented by a float value and ends up overflowing during conversion
anyway. We need to use a slightly smaller float value, which ends up
with slightly inaccurate results for samples which clip or nearly clip,
but it is close enough. Using doubles as intermediates in the conversion
would be more accurate, but it takes about twice as much time.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
