[FFmpeg-devel] ID3v2 demuxer

[Tomas Härdin]

ons 2024-11-27 klockan 08:34 +0100 skrev Anton Khirnov:
> > 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.

Blasphemy. But yes, it is MXF parlance for that. It also uses the term
"sound" instead of audio and "picture" instead of video.

> > We do not pretend rawvideo or pcm_s16le are actual containers
> > either.
> 
> We actually do, we do have demuxers for them.

I didn't say we don't have demuxers for them, I said they're not actual
containers.

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

Passing the wrapped URLContext is one issue. You could pass it as
intptr_t in an AVOption, but that felt extremely cursed. Surely there's
a better way? I suppose I could add a field to some relevant struct..

Another issue is avio's buffer logic. At the moment it isn't engineered
for a file's data changing under its feet. Perhaps dropping the buffers
after ID3v2 is detected and wrapping is done, is enough. Seekability
complicates this.

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

Do you mean ID3v2 headers or ID3v2 as part of AVI metadata? The former
wouldn't be an AVI file, and the present logic rightfully rejects such
files. The same goes for AIFF, where ID3v2 data is stored in its footer

Some files are polyglots. We must decide what to do with them. MXF is
again an excellent example, because in SMPTE's infinite wisdom they
realized that not demanding that the file start with its own header
allows a plethora of workflows

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

This is already supported. avformat_open_input() can take an
AVIOContext (via AVFormatContext, s->pb) and it then uses it in
init_input()

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

It fits nicely into lavf's model, as opposed to special hacks further
up in lavf. But as I replied to Michael, I'm actually leaning more in
the direction of adding a hack now

/Tomas