[FFmpeg-devel] [PATCH 2/3] lavd/utils: always look at file extension when probing
Sat Nov 13 11:50:39 CET 2010
On Sat, Nov 13, 2010 at 10:39:44AM +0100, Reimar D?ffinger wrote:
> 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
> low probability.
> 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.
As an alternative to auto-detection, hows about a suggestion facility.
This would make it easier for applications to prompt users, when a file
e.g. "the format of this file could not be automatically determined,
despite it being named with mp3 extension. it is probably corruped.
would you like to try opening it with the mp3 demuxer? (y/n)"
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel