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

[Michael Niedermayer]

On Wed, Nov 17, 2010 at 11:07:25PM +0100, Reimar D?ffinger wrote:
> 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,

agree


> 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...

well if people want it iam not against

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- 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/20101120/81c65395/attachment.pgp>