[FFmpeg-devel] [PATCH v3 3/3] aadec: fix seeking in mp3 content

[Michael Niedermayer]

On Mon, Jul 02, 2018 at 07:21:43PM +0200, Karsten Otto wrote:
> 
> > Am 02.07.2018 um 10:59 schrieb Michael Niedermayer <michael at niedermayer.cc>:
> > 
> > Signierter PGP-Teil
> > On Thu, Jun 21, 2018 at 06:58:26PM +0200, Karsten Otto wrote:
> >> MP3 frames may not be aligned to aa chunk boundaries. After seeking,
> >> scan for the next valid frame header. Then truncate the packet, and
> >> also adjust timestamp information accordingly.
> >> ---
> >> libavformat/aadec.c | 33 ++++++++++++++++++++++++++++-----
> >> 1 file changed, 28 insertions(+), 5 deletions(-)
> > 
> > Please see AVSTREAM_PARSE_TIMESTAMPS
> > 
> > This codec specific code in demuxers should not be needed
> > 
> I tried that before, and you are right that it takes care of timestamp adjustments.
> 
> However, after a seek the parsed packet still contains a partial frame before the
> next full one. I had expected libavformat/mpegaudio_parser.c to detect this
> situation and discard the fragment, but unfortunately it does not. Instead it passes
> it unchanged to the codec, which plays it as a pop or even a very ugly BLEEEP -
> painful while wearing headphones!

I think you mis-diagnose this at least somewhat
your code searches for a specific mp3 header, the parser and decoder would
accept a wider range of mp3 variants.
But both can choose points that are not mp3 frame starts. (if that is the
problem you are seeing, iam not completely sure it is)

Also is the more restricted header you search for always used or could
this be failing with some files ?

Either way, looking at the demuxer a bit deeper, theres a TOC list in the
main header which points to chunks. The one file i found has 12 such chunks
the first represents the whole file i suspect, the next largest the audio
data, another one the metadata.
I guess the remaining 2 large ones could be a cover image and an index.
I didnt really look at it, but theres a table in there with pairs of 32bit
values. the first in the file i have goes from 0 to 3 the second starts
multiple times from 0 and seems monotonly increasing and staying within
the filesize.
The sample i have does not store mp3 but it looks like this is a index
maybe offsets for packets in each of the 3 chapters.

Please look at the data, if it can be used. It would be much better than
scaning the file linearly and searching for some byte sequence to find
packet starts.


thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180703/297c8457/attachment.sig>