[FFmpeg-devel] [PATCH] IVF demuxer

[Reimar Döffinger]

On Sun, May 23, 2010 at 01:08:03PM +0200, Michael Niedermayer wrote:
> On Sun, May 23, 2010 at 12:25:21PM +0200, Reimar D?ffinger wrote:
> > > also the rate of false positives should be weighted against the rate of false
> > > negatives when deciding what to check and what not.
> > 
> > Yes, thus the criteria was "do such samples exist in the wild". If the answer is
> > not there is not going to be any false negatives.
> 
> if we drop support for everything that we havnt seen, little will be supported
> i think

Obviously not a rule to be applied blindly.

> > > and it can be quite usefull to be able to demux a file even if we cannot
> > > decode it, for debuging and implementing and fixing ...
> > 
> > You don't need a probe function for that, you can select the demuxer to use
> > for that case.
> 
> i can also use a hex editor or write code with cat >file.c but i prefer if
> things work and arent designed to require extra work right and left.
> call me lazy if you like ...

Sure, however if the read_header function would fail anyway you'd have to
do some extra work anyway.

> > > > but IMO unless it is too complex to implement
> > > > a probe function _must_ fail for all files where read_header would fail.
> > > 
> > > the probe function checks if "this" is for example mov, it does not check
> > > if our mov demuxer supports all features to demux it. These are 2 seperate
> > > things and its not the job of probe to reject files with features we do not
> > > support. Thats quite unwanted behavior, it would only lead to the file being
> > > detected as ac3 or mp3 with low score especially if it contains an audio track
> > > with mp3
> > 
> > Maybe if it is a missing feature. However if it is something like sample rate
> > for a raw PCM stream being 0 then it's most likely not just a (minor) missing
> > feature but a completely different format.
> 
> do you have a single example where this was the case?

Well, I was talking about this case mostly, if the frame rate is 0/0 av_set_pts IIRC
can't handle it, and I thought for this format the value also can't really be
determined from the video stream.
Given that the check originally only checked for 4 ASCII characters followed by 2x0
having probing fail for 0/0 timebase seems a far more reasonable choice.
I don't mind so much now, however at least in this case I still see little point
in probe accepting such files, since read_header will fail and I don't have any idea
how it coudl be fixed - unless using -r would actually work for this...

> > Also I have some doubts how often complete failures in read_header are just
> > missing feature support, this after all means we can't even figure out which
> > tracks the file contains, otherwise IMO read_header should not fail.
> 
> making probe fail in all cases where read_header fails would make it probably
> about as fast as read_header, i dont think this is terribly good we could
> call read_header() directly if we wanted exactly its semantics.

I already wrote "unless it is too complex". Also we can't call read_header
since it does not generate a score.