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

[Reimar Döffinger]

On Tue, Nov 09, 2010 at 01:58:13PM +0100, Michael Niedermayer wrote:
> On Tue, Nov 09, 2010 at 08:27:47AM +0100, Reimar D?ffinger wrote:
> > On Tue, Nov 09, 2010 at 02:40:33AM +0100, Michael Niedermayer wrote:
> > > On Mon, Nov 08, 2010 at 04:00:43PM +0100, Anton Khirnov wrote:
> > > > 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?
> > > 
> > > what do you want me to comment about?
> > > 
> > > if its about applications not increasing the probe buffer size and provide
> > > a too small buffer then these are out of luck, thats not our problem. They
> > > either can provide a buffer large enough or support retrying with larger
> > > buffers
> > 
> > I think the patch I sent, that returns a score but no format if an ID3v2 tag
> > was found but no format-specific data after that.
> 
> i think that patch is a bad idea

Ok.
However I just stumbled over r17008 which added the
"else if(buf0!=p->buf)  return AVPROBE_SCORE_MAX/4-1;".
It was supposed to be a hack for large ID3v2 hacks, but it is broken
now.
However it is even more broken since that condition will trigger for
all raw MPEG-ES files and anything else that starts with a 0 byte!
So I think it definitely should be removed, but I was wondering if
it's maybe worth to add a special-case hack to e.g. do
"ID3v2 tag and no other format detected -> return mp3 with score 1"
or something like that.
I don't really like it, but it seems to come up again and again as
something users seem to want...