[FFmpeg-devel] [PATCH 2/3] lavd/utils: always look at file extension when probing

Michael Niedermayer michaelni
Sun Nov 14 04:49:47 CET 2010

On Sat, Nov 13, 2010 at 10:22:38AM +0100, Anton Khirnov wrote:
> On Fri, Nov 12, 2010 at 07:15:17PM +0100, Michael Niedermayer wrote:
> > On Fri, Nov 12, 2010 at 06:18:10PM +0100, Anton Khirnov wrote:
> > > ---
> > >  libavformat/utils.c |    5 +++--
> > >  1 files changed, 3 insertions(+), 2 deletions(-)
> > 
> > rejected
> > this can (and i wager a bet it will) break things.
> what would it break?
> > and you provide no example that it fixes so its same or worse than svn
> This is related to the issue i mentioned before -- files with huge id3v2
> headers fail to be detected if the buffer isn't large enough. Yes i know
> the solution is to provide a bigger buffer, but IMO lavf should do the
> best possible guess with the information it has and that includes the
> file extension.
> Anyway, if you're dead set against using file extensions, why are they
> even there?

you are a physicist?

lets say you have 2 detectors that can detect the polarization (vertical or
horizontal) of 2 photons
these photons are created by some black box you know nothing about beyond
that it has a switch you can flip to mp3 or to aac"
if its mp3 each detector taken alone will detect 90% of the time a vertically
polarized photon, while if its in the aac position each will detect 90% of
the time a horizontally polarized one. The remaining 10% of teh time we assume
the other polirization is detected.

now what your patch does in this context is to assume that 2 vertical detections
will change your knowledge of the switch from 90% to 99%.

I think its obvious why this doesnt work, if not consider that both detectors
might always return identical results, the combined probability would just be
90% not 99%

besides this theory there are very practical issues that result in this
even with just a +1 to cause issues.
it starts out like mpeg-ps and mpeg-es being named .mpg by users and
users naming videos .avi and audio .mp3 no matter what it actually is,
this makes correct detection of the affected files alot harder if all of a
sudden probes dont only have to be +1 better than the next best but +50

or to say it differently misnamed files (which is a real thing) will become
a really hard to probe correctly while i dont think that the gain on correctly
named files will match what we loose.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- 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/20101114/f9860928/attachment.pgp>

More information about the ffmpeg-devel mailing list