[FFmpeg-devel] [PATCH] common ID3v2 support for all formats

[Anton Khirnov]

On Wed, Nov 03, 2010 at 11:12:07PM +0100, Reimar D?ffinger wrote:
> On Wed, Nov 03, 2010 at 11:05:41PM +0100, Reimar D?ffinger wrote:
> > On Wed, Nov 03, 2010 at 10:40:30PM +0100, Anton Khirnov wrote:
> > > On Fri, Oct 01, 2010 at 08:21:07PM +0200, Reimar D?ffinger wrote:
> > > > Hello,
> > > > considering issue 2258 I think it is a valid conclusion that people
> > > > will prepend a ID3v2 header to anything that can't run aways fast enough
> > > > (and then give it a .mp3 extension...).
> > > > So I propose attached patch that moves that parsing to common code.
> > > > Note that is assume that due to buffering the ID3 parsing attempt
> > > > will not cause any issues even on non-seekable input.
> > > > Note that I have no idea WTF the mpc demuxer code is doing there,
> > > > my conclusion was that it should be safe to just throw it all away,
> > > > but I'm not 100% sure I don't miss some subtlety.
> > > > Mostly unrelated, but one issue with this whole ID3 handling is
> > > > that AFAICT it will use the file-specific metadata conversion
> > > > instead of using always the ID3 one.
> > > This change broke detection of mp3 files with really big id3v2 headers
> > > in MPD, which uses a small 64kb buffer. This is probably MPD's fault,
> > > but perhaps there should be a way for av_probe_input_format to signal
> > > that "the stream looks useful, need more data" -- which would be done e.g.
> > > when an id3 header is found which is bigger than the probe data buffer.
> > 
> > I'd suggest to just set score_max, something like below.
> > Of course doesn't work so well for anyone calling it with
> > *score_max == AVPROBE_SCORE_MAX/4 from the start.
> 
> On second thought though I have to say that I can't think of a use
> case. Any app should retry with larger buffers until either there's
> a match with score > AVPROBE_SCORE_MAX/4 or there is a reason to not
> provide more data.
There's always a reason not to provide more data -- speed. Reading very
large probes can take quite long for remote files. The MPD author is
reluctant to do this unless there's some hint the file is not garbage.

> You can't expect "if I pass at least n bytes I'll get at least some
> indication if this is a valid format" unless n is the whole size...
> I also don't think that the previous code was really better, I suspect
> that MPD would have detected all formats with a large ID3v2 header as
> MP3, even if it was actually a wav or other file.
Yes, that's correct. But in most cases they really were mp3s. Right now
all those files are discarded, which is clearly worse.

-- 
Anton Khirnov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101104/9dc14cd7/attachment.pgp>