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. /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
