[FFmpeg-devel] [PATCH] IVF demuxer

[Michael Niedermayer]

On Sun, May 23, 2010 at 12:25:21PM +0200, Reimar D?ffinger wrote:
> On Sun, May 23, 2010 at 11:40:31AM +0200, Michael Niedermayer wrote:
> > IMO the probe function shouldnt touch witdh/height/sample_rate unless it is
> > not possible to detect the format reliably without such hacks.
> 
> width/height maybe, but what's the point for sample rate assuming the read header
> function will definitely fail?

which sample rate would that be?


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


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


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


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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100523/b0bd318f/attachment.pgp>