I was sadly unable to find a non fuzzed mp3 that uses the
feature that contained the bug (and i searched hard ...), thus
while this fixes the security issue. It may or may not fix
mixed blocks in 8khz mp3s, i cant say due to lack of samples to test.
Security issue exists since: b37d945dd4
Reported-by: Dale Curtis <dalecurtis@google.com>
(Probably) Found-by: inferno@chromium.org
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes some DNXHD files generated by AVID TM, where codec UL was set to A-law
meanwhile the real audio codec was PCM S16. According to SMPTE RP 224, A-law is
the default value for sound essence parameters therefore we should handle it
specially.
Signed-off-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Tomas Härdin <tomas.hardin@codemill.se>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Implement av_buffersink_read() and av_buffersink_read_samples()
for ffmpeg's version of buffersink.
With this change, avconv linked against ffmpeg's libraries passes
the same number of tests whether it uses ffbuffersink or
buffersink_old.
* qatar/master:
nutdec: const correctness for get_v_trace/get_s_trace function arguments
truemotion2: Request samples for old TM2 headers
rtpdec: Remove a useless ff_ prefix from a static symbol
rtpdec: Support depacketizing speex
rtpenc: Add support for packetizing speex
Conflicts:
libavformat/rtpdec.c
libavformat/sdp.c
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Also factorize the common options for the different mov-based tests.
Since the header is now on top in the last generated file, the data
offset in the seek test needed some updates as well.
At the moment, the moov header is written at the end of the file, so we
can use the current offset (which focus on the end of the mdat already
written) to guess if 64-bits offset will be required or not.
Though, the next commits will make possible the writing of this table at
the beginning, so this heuristic can't work. As a consequence, we check
all the values within the potential offset table for any value >
32-bits.
Normally we discard things prior to the intended start
for stream copy this is not always possible, and its not done by default
this option allows discarding to be enabled
this is primarely usefull when transcoding a video and stream copying an
audio stream.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Previously we had ignored the past dts and just filled in from the
point where we have had sufficient information.
This should fix Ticket1734
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This packetization scheme simply places the full packets into the
RTP packet without any extra header bytes.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reverts commit d25f87f517.
This breaks decoding of some h264 files
I have tested the original patch with fate but by mistake have
forgotten to specify the fate samples so testing was limited to
the internal regression tests.
* qatar/master:
xsub: feed init_get_bits the whole buffer
libfdk-aac: Allow setting VBR modes via a private option
libfdk-aac: Warn the user that the VBR modes are unsupported
Revert "cbrt_tablegen: Include libm.h"
Conflicts:
libavcodec/xsubdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Discard unflexible structure based on the root/chapter/section layout in
favor of a generalized concept of section.
This should allow to represent sections at a generic level of nesting,
and allow subsection fields selection.
Also, simplify the code.
All versions of MinGW-w64 prior to version 3, as well as
all versions of MinGW32 have broken implementations of
vsnprintf.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Do not use rlelen field for buffer size in init_get_bits, it is
only the size of the data for the first field.
Since it is not reliable, just use the size of the whole buffer.
Additional comments add removal of unused rlelen variable by
Reimar Döffinger.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This avoids using the global_quality field and QSCALE flag for
passing the VBR modes, since the value range of the global_quality
field doesn't really map cleanly to this codec's VBR modes.
Signed-off-by: Martin Storsjö <martin@martin.st>
These modes were not originally exposed by the library at all.
In practice, only a few of them work for each sample rate/profile
combination, and they don't work at all for the more uncommon
sample rates.
Signed-off-by: Martin Storsjö <martin@martin.st>
