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.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Commits 43bc5cf9 and c5371f77 add code for skipping initial zeros in mp3
packets. This code forgot to report to the user that data was skipped at
all.

Since audio codecs allow partial packet decoding, the user application
has to rely on the return value. It will remove the data reported as
consumed by the decoder, and feed it to the decoder again. This resulted
in the mp3 frame after the zero region to be decoded over and over
again, until the zero region was finally skipped by the application.

Fix this by including the amount of skipped bytes to the number of
consumed bytes returned by the decode call.

Fixes trac ticket #4890.

Convert doxygen to multiline and express bitfields more simply.

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

This fixes a segfault when decoding multi-channel MP3onMP4 files.

This is similar to commit cb72230d for MPADSPContext.

Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

14496-3 suggests packing main_data of MP3 that is usually scattered
into multiple frames due to bit reservoir.

However, after packing main_data into a access unit, bitrate index
in the MPEG audio frame header doesn't match with actual frame size.

In order to accept this, this patch removes unnecessary frame size
checking on mp3 decoder.

Also, mov demuxer was changed to use MP3 parser only on special cases
(QT MOV with specific sample description) to avoid re-packetizing.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Fixes rounding difference between 32bit x86 and 64bit
Fixes fate failure with gapless mp3

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes memleak

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

This makes the mp3 decoder produce the same result when repeatly flushing and decoding

Suggested-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes use of uninitialized memory
Fixes: msan_uninit-mem_7f80bf9a259e_5774_id5_1.mp4
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

It seems the code assumed that when one out of multiple blocks fail
some span of time is correct, its not, its some channels
that are correct

Fixes use of uninitialized memory
Fixes: msan_uninit-mem_7f44a03ba3ce_5692_id5_1.mp4
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This fixes decoding, broken since 7e35037.

This is similar to what was done for the normal mp3 decoder in
f4a86bc9.

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

The CONFIG_ name-space is set by configure, so its better to use a
different prefix here.
This also unifies the encoder & decoder define that is used

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This is similar to the fix in 35cbc98b.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Coccinelle profile used:

  @@
  expression r, ctx, f, loglevel, str, flags;
  @@

  -if ((r = ff_get_buffer(ctx, f, flags)) < 0) {
  -    av_log(ctx, loglevel, str);
  -    return r;
  -}
  +if ((r = ff_get_buffer(ctx, f, flags)) < 0)
  +    return r;

  @@
  expression r, ctx, f, loglevel, str;
  @@

  -if ((r = ff_reget_buffer(ctx, f)) < 0) {
  -    av_log(ctx, loglevel, str);
  -    return r;
  -}
  +if ((r = ff_reget_buffer(ctx, f)) < 0)
  +    return r;

  @@
  expression r, ctx, f, loglevel, str, flags;
  @@

  -if ((r = ff_thread_get_buffer(ctx, f, flags)) < 0) {
  -    av_log(ctx, loglevel, str);
  -    return r;
  -}
  +if ((r = ff_thread_get_buffer(ctx, f, flags)) < 0)
  +    return r;

...along with some manual patches for the remaining ones.

This makes wmadec/enc, twinvq and mpegaudiodec (i.e. mp2/mp3)
independent of dsputil.

The larger (and really ugly) size is not needed anymore.

Found-by: Justin Ruggles
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

It will be useful in the upcoming transition to refcounted AVFrames.

The first parameter is a pointer and NULL is more correct

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Also reorder some other #include when applicable.

Properly forward mp_decode_layer3 errors, mp_decode_layer1 and
mp_decode_layer2 do not return errors.

Based on a patch by Michael Niedermayer.

The function can return either a parsing error or a memory management
error.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The value should be always 3, as it follows from the specification.

Fix a stack buffer overflow in exponents_from_scale_factors as reported
by asan. Thanks to Dale Curtis for the sample vector.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

It's a perfectly normal situation, nothing to spam about.