GNOME Bugzilla – Bug 526173
[typefinding] fails to detect mpeg video stream whereas mplayer plays it properly
Last modified: 2008-04-30 21:01:01 UTC
Please describe the problem: typefind is unable to detect mpeg elementary streams that doesnt have the sequence header ie 0x000001b3 as first 4 bytes of the stream. Steps to reproduce: 1.any mpeg elementary stream in which first 4 bytes are not 0x000001b3. 2.GST_DEBUG=2 gst-launch -v filesrc location=elementary_stream.mpeg ! decodebin ! fakesink Actual results: Setting pipeline to PAUSED ... 0:00:00.604053000 24294 0x804e070 WARN GST_PADS gstpad.c:674:gst_pad_set_active:<typefind:sink> Failed to activate pad ERROR: Pipeline doesn't want to pause. ERROR: from element /pipeline0/dec/typefind: Could not determine type of stream. Additional debug info: gsttypefindelement.c(737): gst_type_find_element_activate (): /pipeline0/dec/typefind Setting pipeline to NULL ... FREEING pipeline ... Expected results: typefind should detect the stream as mpeg Does this happen every time? yes Other information:
Created attachment 108612 [details] [review] Fixes this bug. Probes 100kb of data to search the sequence header instead of just first 4 bytes.
Could you attach the beginning of the file in question by any chance? (for test suite purposes) $ head --bytes=990k foo.mpg > foo-head.mpg
Created attachment 108619 [details] first few bytes of the test stream attached
Could you please attach or e-mail me more data than just the first 15000 bytes, so I can figure out why the other typefind function doesn't pick it up properly (or rather that it does in fact with my fixes).
This should fix it: 2008-04-30 Tim-Philipp Müller <tim.muller at collabora co uk> * gst/typefind/gsttypefindfunctions.c: (mpeg_video_stream_ctx_ensure_data), (mpeg_video_stream_type_find), (plugin_init): Rework mpeg video stream typefinding a bit more: make sure sequence, GOP, picture and slice headers appear in the order they should and that we've in fact at least had one of each; fix picture header detection; decouple picture and slice header check - don't assume they're at a fixed offset, there may be extra data in between. Also, announce varying degrees of probability depending on what we found exactly (multiple pictures, at least one picture, just sequence and GOP headers). Finally, in _ensure_data(), take into account that we might be typefinding smaller amounts of data, such as the first buffer of a stream, so fall back to the minimum size needed as long as that's available, instead of erroring out if there's less than 2kB of data. Fixes #526173. Conveniently also doesn't recognise the fuzzed file from #399342 as valid. The function your patching shouldn't really be needed at all (I've removed it now), mpeg_video_stream_type_find() should pick it up. But even if not, your patch isn't really ideal, since it calls gst_typefind_peek() not less than a hundred thousand something times (!) in the worst case, e.g. if this is not an mpeg video stream and there wasn't random data that happens to look like a sequence header and no other typefinder short-circuited the typefinding process with a PRIMARY probability. Please re-open if this doesn't fix it for the full file. Thanks!