After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 526173 - [typefinding] fails to detect mpeg video stream whereas mplayer plays it properly
[typefinding] fails to detect mpeg video stream whereas mplayer plays it prop...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal normal
: 0.10.20
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-04-04 15:46 UTC by kapil
Modified: 2008-04-30 21:01 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
Fixes this bug. (1.65 KB, patch)
2008-04-04 15:49 UTC, kapil
rejected Details | Review
first few bytes of the test stream attached (14.65 KB, video/mpeg)
2008-04-04 16:49 UTC, kapil
  Details

Description kapil 2008-04-04 15:46:13 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:
Comment 1 kapil 2008-04-04 15:49:06 UTC
Created attachment 108612 [details] [review]
Fixes this bug.

Probes 100kb of data to search the sequence header instead of just first 4 bytes.
Comment 2 Tim-Philipp Müller 2008-04-04 16:38:37 UTC
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


Comment 3 kapil 2008-04-04 16:49:46 UTC
Created attachment 108619 [details]
first few bytes of the test stream attached
Comment 4 Tim-Philipp Müller 2008-04-29 15:55:16 UTC
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).
Comment 5 Tim-Philipp Müller 2008-04-30 21:01:01 UTC
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!