On Mon, 8 May 2017 16:25:43 -0400
Vadim Kalinsky <[email protected]> wrote:
> Hey,
>
> Trying to fix a bug #6113, I stumbled upon some strange logic in
> libavformat/img2dec.c:jpeg_probe. It accepts first 2048 bytes of jpeg stream,
> and tries to read it with some state machine. If it doesn't look like jpeg
> stream, it returns 0 ("it's definitely not a jpeg").
>
> After it read through the buffer, it does this:
>
> if (state == EOI)
> return AVPROBE_SCORE_EXTENSION + 1;
> if (state == SOS)
> return AVPROBE_SCORE_EXTENSION / 2;
>
> return AVPROBE_SCORE_EXTENSION / 8;
>
>
> That doesn't make sense to me. All we read so far made sense for jpeg reader,
> it definitely looks like a jpeg image, but for some reason our confidence is
> AVPROBE_SCORE_EXTENSION _DIVIDED_ by 2 or 8 (in other words, "it would look
> more jpeg if it had .jpg extension).
These are all heuristics mostly a certain developer tuned and who
decided it'd make sense.
The problem with probing is that it uses a score system, which means
ambiguous formats get distinguished by the rather arbitrary score
across all the other probers, which makes this messy.
I'd say just send a patch.
_______________________________________________
ffmpeg-devel mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
