tor 2024-11-14 klockan 01:26 +0100 skrev Michael Niedermayer: > On Wed, Nov 13, 2024 at 03:26:40PM +0100, Tomas Härdin wrote: > > ons 2024-11-13 klockan 14:40 +0100 skrev Michael Niedermayer: > > > Hi > > > > > > On Tue, Oct 29, 2024 at 03:44:30PM +0100, Tomas Härdin wrote: > > > > Needs a sample. An option or setting for probe size might be a good > > > > idea > > > > > > > > Spotify comments > > > > ---------------- > > > > In mp3 files, id3v2 tag with huge cover art causes the probe code > > > > to > > > > not identify valid mp3 files as mp3. Increase default buffer so > > > > that > > > > probe can see mp3 frames. > > > > > > Does this work if its limited to cases where huge ID3 is detected ? > > > or we could seek forward over the ID3 detect format and then go > > > back and do the normal open code > > > > Can't we have it just rely on there being an ID3 header? Are there > > counterexamples? > > > > > The probe logic (av_probe_input_format3()) has special logic for ID3 > > headers, skipping past them to allow the normal MP3 probing to inspect > > the essence data following the header. This only works if it's given > > enough probe data > > > > Seeking can be expensive, especially when the data is served over HTTP > > anything that works is fine. The better it works, the more often, > the better > > If seeking makes sense probably depends on the relative cost of seeking > vs. bandwidth
True. Even in my location, which has among the best internet connectivity on the planet, downloading 16 MiB is non-trivial and probably more expensive than a seek. Perhaps AVIO can be assumed to take care of it with a future cache layer. Such a cache would also allow us to remove many hacks, such as the switch between demuxing mode in avidec. Just set the relevant cache settings for AVIO instead > We already have places where similar decissions needs to be made, like > when deciding if we seek forward or just keep reading. > > One problem with never seeking is that it requires a limit in how > much can be read. Above that a ID3 will fail somehow instead of being slow Having it randomly fail because of passing some magical threshold sounds inelegant and annoying. > I faintly remember that there was prior discussion about seeking and > id3 probing long ago. > Either way i have no real oppinion on this, above is just some dump of > related thoughts. Having investigated this a bit more, I think the best solution would be to implement generic ID3v2 parsing and "stripping" the ID3v2 data higher up in lavf than in any individual demuxer, and having the AVIO layer pretend it isn't there. This would allow removing ID3v2 handling in mp3dec while also supporting pretty much any container with ID3v2 prepended MXF might interact weirdly with this, because of it allowing run-in. On the other hand the intent of run-in is to be able to treat for example .WAV files as MXF if it has an MXF header further in than the RIFF header. IIRC such run-in is always essentially ignored Currently cover art contained in ID3v2 is always put as the last stream, and as the first packet. For example an mp3 on my machine looks like this: Stream #0:0: Audio: mp3, 44100 Hz, mono, fltp, 64 kb/s Stream #0:1: Video: mjpeg (Progressive), yuvj444p(pc, bt470bg/unknown/unknown), 1920x1080 [SAR 300:300 DAR 16:9], 90k tbr, 90k tbn (attached pic) The first packet output by mp3dec is the cover art, then comes the MP3 packets. Things might be slightly easier if these streams are allowed to be rearranged, such that the video is stream #0:0. Either way, the way I see it there are three cases: 1) the file is not seekable 2) the file is seekable but AVDISCARD_ALL has been set on the video stream 3) the file is seekable and AVDISCARD* has not been set For 1) there's nothing we can do but keep on reading. For 2) we can't have the probe logic read the ID3v2 only to then "discard" the data. That would be silly. 3) is similar to 1). So the one case to worry about are when users aren't interested in the cover art. They might be interested in other metadata contained in ID3v2 though. I would also suggest that we reject any container format not in an explicit whitelist so as to not encourage proliferation of incredibly cursed combinations such as: * ID3v2 + MXF * ID3v2 + ID3v2 + ... * ID3v2 + [any non-audio container] * ID3v2 + [any container that already support cover art] and so on. We should demand samples demonstrating the need for ID3v2 handling and/or reference specific standards mandating it, even if we in principle could handle any arbitrary combination /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".
