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

[Anton Khirnov]

On Thu, Nov 04, 2010 at 08:04:32AM +0100, Reimar D?ffinger wrote:
> On Thu, Nov 04, 2010 at 07:53:19AM +0100, Anton Khirnov wrote:
> > On Wed, Nov 03, 2010 at 11:12:07PM +0100, Reimar D?ffinger wrote:
> > > 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.
> 
> Can you describe the use case in more detail? Because considering
> "speed" in case probe has failed is kind of like "my program is really
> fast at not doing anything!".
Well it's always some kind of tradeoff between how reliable you want
detection to be and how long you're willing to wait for that. If we can
provide further hints to make the process easier, IMO we should do that.

> Also for fast probing something like the "file" program might be a better
> approach...
> Anyway I did propose a patch, and I'm interested in feedback from you
> and Michael.
i guess it might be a good enough solution. (some docs and a minor bump
are probably should probably be added)
Michael - ping?
> 
> > > 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.
> 
> Only in that specific implementation. In principle I think it is more correct:
> an ID3v2 header on its own is not a media file.
it's not, but it's a big hint that the file might be playable

-- 
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/20101108/1d866cb0/attachment.pgp>