Having more than 10 consecutive frames decoded as mp3 should be
considered a clear signal that the sample is mp3 and not mpegps.
Reported-By: Florian Iragne <florian@iragne.fr>
CC: libav-stable@libav.org
The quality scale field is only supposed to be present if the fourth bit
is set. In practice, lame always sets it, but other tools might not.
CC:libav-stable@libav.org
Consider a file created with something like:
cat file1.mp3 file2.mp3 > result.mp3
Then if file2.mp3 has gapless information, result.mp3 would stop playing
something in the middle. This happens because the gapless info directs
the decoder to discard all samples after a certain position. To make
matters worse, the gapless info of file2.mp3 will be used when playing
the file1.mp3 part, because the gapless info is located at the end of
the file.
While handling concatenated gapless files correctly would be insane and
a lot of effort (especially without scanning the whole file on opening),
it's easy to prevent at least early EOF. Playback will happen to work,
even if it's slightly broken.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The code already had skipping of initial padding, but discarding
trailing frame padding was missing.
This is somewhat questionable, because it will make the decoder discard
any data after the declared file size in the LAME header. But note that
skipping full frames at the end of the stream is required. Encoders
actually create such files.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '32d05934abc7427bb90380a4c1ab20a15fd7d821':
mp3dec: decode more data from Info header
Conflicts:
libavformat/mp3dec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'fbd8e042107ec63e0ddf155588c59dcb76007641':
mp3dec: move XING/Info and VBRI parsing into their own functions
Conflicts:
libavformat/mp3dec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
When a id3 tag is larger than the amount of space we will probe
give it a score similar to what a .mp3 extension would have given it
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The toc is inexact and not using it can thus make sense.
Using it is faster though, thus the opposite can similarly makes sense
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '505642f18276aed03278ac91b1f334ea888eac6a':
mp3dec: fallback to generic seeking when a TOC is not present
Conflicts:
libavformat/mp3dec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
When parsing the Xing/Info tag, don't set the bit rate if it's an Info tag.
When parsing the stream, don't override the bit rate if it's already set,
otherwise calculate the mean bit rate from parsed frames. This way, the bit
rate will be set correctly both for CBR and VBR streams.
CC:libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When parsing the Xing/Info tag, don't set the bit rate if it's an Info tag.
When parsing the stream, don't override the bit rate if it's already set,
otherwise calculate the mean bit rate from parsed frames. This way, the bit
rate will be set correctly both for CBR and VBR streams.
Signed-off-by: Alexander Kojevnikov <alexander@kojevnikov.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The libav code depends on mp3 startcodes only occuring at the start of
frames. But there is nothing in mp3 that prevents them occuring elsewhere
by chance. Thus the code would fail randomly, the new code searches for 3
consecutive valid frames. If this turns out to be still insufficient the
number can be raised further, or additional checks added.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
mp3dec: read Xing frame TOC index
mp3dec: use named constants for Xing header flags
libx264: add support for nal-hrd, required for Blu-ray streams.
mov: support random access point grouping
matroskadec: properly support BlockDuration
Conflicts:
libavcodec/libx264.c
libavformat/isom.h
libavformat/matroskadec.c
libavformat/mov.c
libavformat/mp3dec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
