GNOME Bugzilla – Bug 579692
mp3_type_find is over-optimistic
Last modified: 2009-05-07 13:01:13 UTC
Typefind may identify an H.264 stream as an MPEG-1 audio stream (with a low probability) when it has not yet received sufficient data to identify it as an H.264 stream. I'll attach a sample stream. With gst-launch -v filesrc location=foo.h264 ! typefind ! fakesink silent=true it finds caps = video/x-h264 With gst-launch -v filesrc location=foo.h264 ! queue ! typefind ! fakesink silent=true it finds caps = audio/mpeg, mpegversion=(int)1, layer=(int)1 The queue makes typefind operate in push mode, so it is (initially) limited to the first 4096 bytes, which don't contain sufficient H.264 slice headers yet to identify it. mp3_type_find sets the probability at 20 so it wins. I haven't tried with git head but (looking at the diffs of typefindfunctions.c) don't see how it would make a difference. Proposed patch will follow
Created attachment 133021 [details] Example stream that may be identified as MPEG-1 audio typefind identifies this stream as MPEG-1 audio if only part of it is provided.
Created attachment 133029 [details] [review] typefindfunctions: made mp3_type_find less aggressive mp3_type_find could suggest already when only a single valid header was found, if it ran out of data before the end of the next frame. Therefore, ignore the last found frame if it was incomplete.
Created attachment 133030 [details] [review] typefindfunctions: made mp3_type_find less aggressive Previous patch did wrong detection of end of data.
Thanks, committed locally and will push after the freeze. commit 9eebc2249931c04cff0ce3fcf3546863e8f65c07 Author: Arnout Vandecappelle <arnout@mind.be> Date: Thu May 7 14:59:36 2009 +0200 typefindfunctions: made mp3_type_find less aggressive mp3_type_find could suggest already when only a single valid header was found, if it ran out of data before the end of the next frame. Therefore, ignore the last found frame if it was incomplete. Fixes bug #579692.