Justin Ruggles writes: > In terms of how the score for a MIME type match compares with > those of the individual content matching probe functions, I'd > say it makes sense. The stronger probing functions have a > score which reflects their reliability.
But even _EXTENSION + 1 is correct in practically all cases (the exception are mpeg streams that start with the needed four bytes) and should not be beaten by mime_type. > Improves probing, especially over http when there is a > Content-Type header Please give an example of a failing stream. If you cannot share, please provide console output and hexdump of the relevant bytes. If this cannot be fixed differently, we should either increase the score for the existing 32bit probe functions or reduce the score for mime types before this gets applied. Several probe functions (outside of img2dec.c) return MAX for 32 bits, I just wanted to give problematic mpeg streams a better chance to get detected. The alternative is to only use mime type for jpeg: I am assuming this is the only problematic case, note that we have to make sure it's not mjpeg, that's why the probe function is so long. > If a MIME type is specified, that does have significant weight > in terms of probability, given that it was set somewhere either > by a client or server program doing a content check or > explicitly by some user. Wouldn't the server simply run "file" doing less checks than we already do now? (If it doesn't trust the extension.) Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
