[FFmpeg-devel] ID3v2 demuxer

[Michael Niedermayer]

On Tue, Nov 26, 2024 at 05:24:42PM +0100, Tomas Härdin wrote:
> sön 2024-11-24 klockan 02:37 +0100 skrev Michael Niedermayer:
> > Hi
> > 
> > On Fri, Nov 22, 2024 at 03:50:18PM +0100, Anton Khirnov wrote:
> > > 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
> > 
> > same here, also not a fan of the idea.
> > 
> > also i think id3 is sometimes put infront of things that need a demuxer
> > 
> > AFAIK the chain of events is this:
> > * some hw or sw players / web service or other support a wide range of formats
> >   but only allow files with the file extension .mp3
> > * Users have vorbis, flac, aac, wma, ... files and want to play them without
> >   loss
> > * they rename them to .mp3
> > * somewhere down the line a tool adds a id3 header to a .mp3 file and the file
> >   is shared somewhere
> 
> We don't have to support literally any hypothetical workflow we can
> dream up. The motivation here is that there are specs like HLS that
> require support for ID3v2 not just for MP3. And of course that Spotify
> is paying for it
> 
> I'm actually leaning back towards putting the ID3v2 handling in
> format.c/demux.c. Being able to probe a file from offsets other than
> zero and rewinding to that offset then becomes useful. This still
> requires cooperation from the demuxer which isn't ideal
> 

> A fully generic solution requires the ability to wrap an existing
> AVIOContext, because the user may have provided a custom one. The
> problem I ran into with this is the buffer logic around avio.

yes, indeed, i agree, a fully generic one seems too much work

thx

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20241127/b2a3372d/attachment.sig>