[FFmpeg-devel] confusing trailing metadata for mpeg frames

[David Byron]

Michael Niedermayer wrote:

> when a mp3 file is read we seek to the end and parse all the tags,
> it shouldnt be hard to check durig packet reding where we are and skip
> the amount that we previously determined belongs to non mp3 data

I've written some code to do this, but I've clearly got it wrong.  It finds
the offset of trailing metadata correctly in the attached file, but I'm not
using the offset correctly to prevent av_read_frame from returning the
trailing metadata in a packet.

Would someone please take a look at this and help point me in the right
direction?  I've added some logic based on url_ftell(s->pb) in
mp3_read_packet but it's either incorrect or insufficient.  url_ftell
doesn't seem to give me quite the right info, but even if it did it seems
like I need to put some logic elsewhere to pull this off.

Here's the output of ./iterate_frames ape_and_id3v1_with_audio_5.mp3.  It is
a hand-created file, but it's a straight copy of 5 mpeg frames from a legit
audio file (1 Info frame + 4 actual audio frames) along with actual APE +
id3v1 tags.  In other words I expect ffmpeg to process it just like the
original file.  Please let me know if this is an acceptable way to reduce
the file size to ease sending the file around.

$ ./iterate_frames ape_and_id3v1_with_audio_5.mp3
[NULL @ 0x16b4010] Probed with size=2048 and score=51
[mp3 @ 0x16b4010] ff_mp3_find_trailing_metadata:
"ape_and_id3v1_with_audio_5.mp3": id3v1 tag at offset 3339(0xd0b)
[mp3 @ 0x16b4010] ff_ape_offset: "ape_and_id3v1_with_audio_5.mp3": APE Tag
contains header
[mp3 @ 0x16b4010] ff_ape_offset: "ape_and_id3v1_with_audio_5.mp3": 206 byte
APE tag at offset 3133(0xc3d)
[mp3 @ 0x16b4010] mp3_read_packet: "ape_and_id3v1_with_audio_5.mp3": current
offset: 626, trailing_metadata_offset: 3133
"ape_and_id3v1_with_audio_5.mp3": frame 1: offset: 1650, size 626 byte(s)
[mp3 @ 0x16b4010] mp3_read_packet: "ape_and_id3v1_with_audio_5.mp3": current
offset: 1650, trailing_metadata_offset: 3133
"ape_and_id3v1_with_audio_5.mp3": frame 2: offset: 2674, size 627 byte(s)
"ape_and_id3v1_with_audio_5.mp3": frame 3: offset: 2674, size 627 byte(s)
[mp3 @ 0x16b4010] mp3_read_packet: "ape_and_id3v1_with_audio_5.mp3": current
offset: 2674, trailing_metadata_offset: 3133
"ape_and_id3v1_with_audio_5.mp3": frame 4: offset: 3467, size 627 byte(s)
[mp3 @ 0x16b4010] mp3_read_packet: "ape_and_id3v1_with_audio_5.mp3": current
offset: 3467, trailing_metadata_offset: 3133
[mp3 @ 0x16b4010] mp3_read_packet: "ape_and_id3v1_with_audio_5.mp3": giving
up at offset: 3467 due to trailing metadata
"ape_and_id3v1_with_audio_5.mp3": frame 5: offset: 3467, size 334 byte(s)
[mp3 @ 0x16b4010] mp3_read_packet: "ape_and_id3v1_with_audio_5.mp3": current
offset: 3467, trailing_metadata_offset: 3133
[mp3 @ 0x16b4010] mp3_read_packet: "ape_and_id3v1_with_audio_5.mp3": giving
up at offset: 3467 due to trailing metadata
"ape_and_id3v1_with_audio_5.mp3": 5 frame(s), 2841 byte(s)

The things I'd like to see different here are:

- current offset as logged in mp3_read_packet: the offset of the data being
considered for the next packet
- av_read_frame returning < 0 after the first "giving up at offset..." log
message so iterate_frames.c only sees 4 frames.

After looking at the output with FF_FDEBUG_TS set and some single-stepping,
I see that av_read_frame_internal "generates" packets by calling
mpegaudio_parse (and not mp3_read_packet).  I can't see a good way to get
the trailing_metadata_offset into a data structure that mpegaudio_parse has
access to.  Or in some other way communicating that mpegaudio_parse
shouldn't return a packet.  Is AVStream->priv_data the spot?
AVCodecContext->extradata/extradata_size?  Other suggestions?

With any luck after that comes together, determining the correct offset
(instead of url_ftell) will become clear as well.

Thanks for your help.

-DB