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 556537 - [PATCH] typefind: more flexible MPEG4 start code recognition
[PATCH] typefind: more flexible MPEG4 start code recognition
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal minor
: 0.10.25
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 556521 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-10-16 12:59 UTC by Arnout Vandecappelle
Modified: 2009-07-30 13:10 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Trivial patch: also accept stream that starts with a VOP. (721 bytes, patch)
2008-10-16 13:03 UTC, Arnout Vandecappelle
rejected Details | Review
Extended patch, based on mpeg_video_stream_type_find (6.63 KB, patch)
2008-10-16 13:36 UTC, Arnout Vandecappelle
committed Details | Review

Description Arnout Vandecappelle 2008-10-16 12:59:35 UTC
Please describe the problem:
I'm trying to push an MPEG4 stream from a JVC camera into my GStreamer 
pipeline.  However, this camera does not start the stream on a keyframe 
boundary, but just starts emitting the current P frame.  The headers are 
therefore not recognized by typefind, and typefind returns an error.


Steps to reproduce:
gst-launch souphttpsrc location=<JVC camera MPEG4 stream> ! typefind ! fakesink

Actual results:
ERROR: from element /pipeline0/typefindelement0: Could not determine type of stream.

Expected results:
video/mpeg stream recognized

Does this happen every time?
Yes.

Other information:
Cfr. http://sourceforge.net/mailarchive/forum.php?thread_name=200810151518.16026.arnout%40mind.be&forum_name=gstreamer-devel
Comment 1 Arnout Vandecappelle 2008-10-16 13:03:58 UTC
Created attachment 120711 [details] [review]
Trivial patch: also accept stream that starts with a VOP.

This patch simply recognizes a stream starting with 0x00 0x00 0x01 0xb6 as an MPEG4 stream too.  It was suggested on gst-devel.  However, I don't think it's a very reliable way of detecting - perhaps probability should be reduced to POSSIBLE.
Comment 2 Arnout Vandecappelle 2008-10-16 13:36:05 UTC
Created attachment 120716 [details] [review]
Extended patch, based on mpeg_video_stream_type_find

This alternative patch is a cut-and-paste of mpeg_video_stream_type_find.  The expected stream layout is based on http://xhelmboyx.tripod.com/formats/mpeg-layout.txt since I have no better source of information about the MPEG4 standard.  The probabilities returned are a bit of guesswork from my side.

Ideally, this function should be refactored with mpeg_video_stream_type_find (there's a lot of similarity between them).
Comment 3 Arnout Vandecappelle 2008-10-16 13:57:20 UTC
(In reply to comment #2)
> Created an attachment (id=120716) [edit]
> Extended patch, based on mpeg_video_stream_type_find

Oh yes, this patch also fixes #556521 and supersedes its attachment (id=120707).
Comment 4 Sebastian Dröge (slomo) 2008-10-19 11:52:17 UTC
*** Bug 556521 has been marked as a duplicate of this bug. ***
Comment 5 Sebastian Dröge (slomo) 2009-07-30 13:10:24 UTC
I'll push this after 0.10.24 release. Thanks :)

commit efa85af053bfcc66c092732ca03f80929406a2a5
Author: Arnout Vandecappelle <arnout@mind.be>
Date:   Thu Jul 30 15:05:28 2009 +0200

    typefindfunctions: Implement better & more flexible MPEG4 typefinding
    
    This detects more MPEG4 streams as MPEG4.
    
    Fixes bug #556537.