[FFmpeg-devel] [PATCH 2/3] lavd/utils: always look at file extension when probing
Sat Nov 13 10:39:44 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?
Values indicating an unsure detection will suddenly become values indicating
a certain detection.
In case of e.g. MP3 or DV and only let's say the first 12 bytes of a file
in the probe buffer that is almost certain to result in false positives.
> > 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.
File extension can never make a detection reliable, which AFAICT your
patch would pretend to.
Neither can it resolve a conflict if two formats are detected with
And it probably shouldn't be considered a conflict if a format
is only detected with low probability but that does not match
the extension (consider a wav/RIFF file containing MP3, and a lot of
people will give that a .mp3 extension on top. I have also seen
AVI with .mp2, raw MPEG-4 with .mp4, DV in mov with .dv, all
of which have a high risk that this extension "offset" will
make the detection break).
> Anyway, if you're dead set against using file extensions, why are they
> even there?
They're useful information, but your implementation gives them almost
the same priority as the probe function itself, that is not appropriate.
More information about the ffmpeg-devel