[FFmpeg-devel] [PATCH] IVF demuxer
Sun May 23 12:25:21 CEST 2010
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?
> 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.
> a width != 0 check is not going to gain you much in terms of false positives
> but if such file can be demuxed correctly it is a loss in terms of false
For random data, such a check would not gain much, but if you check e.g. with
probetest such a check will gain a lot if all other checks are only against
ASCII characters and 0.
> 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.
> > 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.
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.
More information about the ffmpeg-devel