[FFmpeg-devel] ID3v2 demuxer

[Anton Khirnov]

Quoting Tomas Härdin (2024-11-22 17:10:10)
> 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.

With the semi-standard extensions like xing/info frames it almost has
enough complexity for one.

>It's just an essence stream.

You spent too much time around MXF, consider exorcism. I assume this
piece of jargon means "raw/elementary stream", correct me if I'm wrong.

> We do not pretend rawvideo or pcm_s16le are actual containers either.

We actually do, we do have demuxers for them.

> 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.

For instance?

> 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.

As I remember, there are plenty of samples around of non-mp3 audio files
with an id3v2 header, including complex containers like AVI (or was it
ASF? possibly both).

> 
> > 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.

How about extending the probe API so that it can accept an AVIOContext
and seek in it?

> 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.

How does an id3v2 demuxer help here?

-- 
Anton Khirnov