- 05 Sep, 2015 1 commit
-
-
Andy Wu authored
When AVFMT_FLAG_FAST_SEEK is specified, make MP3 seek operation as fast as possible. When no "-usetoc" is specified, the default operation is using TOC if available; otherwise, uses linear interpolation. This is useful when seeking a large MP3 file with no TOC available. One example is Podcast, many MP3 files are large, but no CBR/VBR tags. Most of them are actually CBR. Even in VBR cases, this option sacrifices the accuracy of playback time in exchange for responsiveness.
-
- 20 Jul, 2015 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 19 Jul, 2015 2 commits
-
-
James Almer authored
Signed-off-by: James Almer <jamrial@gmail.com>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 18 Jul, 2015 1 commit
-
-
Ganesh Ajjanagadde authored
Fixes Ticket4723 Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 13 Jul, 2015 1 commit
-
-
Luca Barbato authored
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 11 Jul, 2015 1 commit
-
-
Luca Barbato authored
Try to parse up to 4 packets to find the closest packet. Reported-By: jan.schlueter@ofai.at
-
- 24 Jun, 2015 1 commit
-
-
Michael Niedermayer authored
The code is simply broken, the read packets are not aligned to the mp3 frames, the file end or the id3 tag thus this simply cannot reliably find the ID3v1 tag to remove it Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 13 Jun, 2015 1 commit
-
-
Carl Eugen Hoyos authored
-
- 27 May, 2015 2 commits
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
wm4 authored
Apparently it can happen that a mp3 file has junk data between id3 tag and actual mp3 data. Skip this to avoid outputting nonsense timestamps. (Two packets had the same timestamps, because the mp3 parser failed to compute a frame duration.) In this case, the junk consisted of 1044 bytes of zero, which incidentally is the same size as normal mp3 frames in this stream. I suspect the mp3 was edited with some tool which wiped the Xing/LAME headers. Data near the end of the file suggests it was encoded with "LAME3.97", but the normal Xing/LAME headers are missing. So this could be "normal". mpg123 also attempts to skip at least 64KB of junk data by scanning for headers. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 24 Apr, 2015 1 commit
-
-
wm4 authored
If the file size is much larger than what is indicated in the XING header, the demuxer assumes it's a concatenated file, and throws away the (presumably) incorrect duration information. Unfortunately, this also triggers if the id3 tags are very large (embedded pictures and such). Then the half-baked heuristic not only breaks the duration display, but also gapless audio. Fix it by subtracting the size of the headers (the check is off by some bytes, but that doesn't matter at all). Note that there could be an arbitrary amount of tags _after_ the mp3 data, but hopefully these are not too large to trigger the heuristic in practice. Also add a warning when this happens. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 22 Apr, 2015 4 commits
-
-
wm4 authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
wm4 authored
It's the most useful mode, because it seeks accurately, and does not break features like gapless audio. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
wm4 authored
"-usetoc 2" now invokes the generic seek and indexing mode. This mode skips data until the seek target is reached, and this is exact. It also makes gapless audio actually work if a seek past the start of the file is involved. Change the fate-gapless-mp3 test to use the new mode, and move the old one to fate-gapless-mp3-toc (since the test forces use of the Xing TOC). The new mode has a different result for the seek - this result is actually correct. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
wm4 authored
The mp2 seek test results change. Whether to skip samples if the file had no LAME gapless tags was inconsistent. When seeking to the start of the file, 529 samples were skipped, but when playing from start, nothing was skipped. This commit changes the behavior on seek to skip nothing. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 20 Apr, 2015 1 commit
-
-
Michael Niedermayer authored
With this the returned timestamp should match the packet instead of the requested timestamp, which may lay between packets Reviewed-by: wm4 <nfxjfg@googlemail.com> Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 17 Apr, 2015 1 commit
-
-
wm4 authored
Removing a bunch of questionable hacks makes it work. These hacks apparently try to make concatenated mp3s with Lame headers seekable, which doesn't make too much sense anyway. The main change is that we trust the Xing header file size field now (the same field is used for seeking with Xing TOC). Note that a mp3 might contain an unknown number of unsupported additional tags, so we can't reliably compute this size manually. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 15 Apr, 2015 3 commits
-
-
wm4 authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
wm4 authored
This reverts commit 8b76c0eb. It was slightly incorrect; the next commit fixes it. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 31 Mar, 2015 1 commit
-
-
wm4 authored
The Xing index won't account for the id3 tag - it's relative to the headers. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 11 Mar, 2015 1 commit
-
-
Vittorio Giovara authored
Rather than having an unitialized context on the stack, allocate it with defaults and free it when unneeded. CC: libav-stable@libav.org
-
- 26 Feb, 2015 2 commits
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Michael Niedermayer authored
Fixes (harmless) use of uninitialized variable Found-by: jamrial Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 14 Dec, 2014 1 commit
-
-
Michael Niedermayer authored
Found-by: nattyzs <nattyzs@163.com> Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 07 Dec, 2014 1 commit
-
-
Luca Barbato authored
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
-
- 18 Nov, 2014 1 commit
-
-
Michael Niedermayer authored
Fixes Ticket4038 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 24 Oct, 2014 2 commits
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
Anton Khirnov authored
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
-
- 21 Sep, 2014 1 commit
-
-
wm4 authored
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>
-
- 20 Sep, 2014 1 commit
-
-
wm4 authored
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>
-
- 10 Sep, 2014 1 commit
-
-
Michael Niedermayer authored
Fixes Ticket3884 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 24 Jul, 2014 1 commit
-
-
Carl Eugen Hoyos authored
Fixes ticket #3777.
-
- 12 May, 2014 1 commit
-
-
Michael Niedermayer authored
Fixes misdetection of issue3327-libc-2.17.so Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 17 Apr, 2014 2 commits
-
-
Alessandro Ghedini authored
Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
Alessandro Ghedini authored
Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
- 24 Mar, 2014 1 commit
-
-
Anton Khirnov authored
-
- 01 Mar, 2014 1 commit
-
-
Michael Niedermayer authored
this minimizes the amount of protocol seeks and reading needed in that case Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 05 Jan, 2014 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-