[FFmpeg-devel] ID3v2 demuxer

[Tomas Härdin]

fre 2024-11-22 klockan 15:50 +0100 skrev Anton Khirnov:
> Quoting Tomas Härdin (2024-11-22 10:51:21)
> > Hi all
> > 
> > So after looking at options for how to better deal with ID3v2 I'm
> > leaning towards creating a demuxer for it. I'm writing this before
> > going any further with it to get some feedback
> 
> Honestly, not a fan of the idea. Does that imply that every file that
> happens to contain an id3v2 header would now probe as id3v2 and not the
> actual format? That would be HIGHLY confusing and probably break a lot
> of assumptions our callers are making.

Yes. Keep in mind mp3 isn't an actual container format. It's just an
essence stream. We do not pretend rawvideo or pcm_s16le are actual
containers either. I'm open to better ideas though.

Another option is adding a suitable "protocol" that strips the header.
This has its own set of problems. I also have a patch for not doing
ID3v2 stuff for formats that don't support it, such as rawvideo.

Note that this stuff wouldn't change proper containers where ID3v2 is
not the header, but contained somewhere else in the file, such as the
footer, for example AIFF.

> Also what I don't see in your email is any mention of what would this
> improve for our callers.

The ability to probe mp3 files with cover art larger than 1 MiB, and
also to skip reading said cover art over a slow connection while still
having functioning probe.

Another concern is HLS, which mandates ID3 support for MP3, AAC, ADTS,
AC3 and EAC3: https://datatracker.ietf.org/doc/html/rfc8216#section-3.4
The spec doesn't say whether by "ID3" it means ID3v1 or ID3v2.

One major oversight with ID3v2 is that it has mime type stored only for
the cover art and not the audio itself. This prevents its use as a
proper grownup container format.

/Tomas