How to make typefind drop data?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How to make typefind drop data?

Arnout Vandecappelle
 Hoi,

 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.

 I would now like to drop data (buffers or bytes) until typefind does
recognize the MPEG4 stream start.  How should I implement this?  I see the
following options:

 - In mpeg4_video_type_find(), be less picky about the start codes, i.e.
accept an isolated B-frame start code as well.
 - Make mpeg4_video_type_find() look ahead more, cfr.
mpeg_video_stream_type_find().
 - In typefindelement, when typefind fails, drop a buffer (or a byte) and
retry.
 - Same as above but from application instead of typefindelement.  Complex to
implement.

 The first two cases don't actually skip over the unrecognized part.  This
happens to be OK for the MPEG4 decoder, but results in some leading garbage
in the output (it assumes a gray reference frame).  It would be nice if it
were possible for typefind to also indicate an offset at which it detected
the type found, and give the application the option to skip over leading
garbage.  That would be a major overhaul, though...

 If I get no reply, I'll implement the second option and submit it through
bugzilla.

 Regards,
 Arnout
--
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to make typefind drop data?

michael smith-6-3
On Wed, Oct 15, 2008 at 6:18 AM, Arnout Vandecappelle <[hidden email]> wrote:

>  Hoi,
>
>  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.
>
>  I would now like to drop data (buffers or bytes) until typefind does
> recognize the MPEG4 stream start.  How should I implement this?  I see the
> following options:
>
>  - In mpeg4_video_type_find(), be less picky about the start codes, i.e.
> accept an isolated B-frame start code as well.

This is probably the best option.


>  - Make mpeg4_video_type_find() look ahead more, cfr.
> mpeg_video_stream_type_find().

This might be worth doing _in addition_ to the first one.

You'll need to be very careful to not trigger false positives when
doing stuff like this though.

>  The first two cases don't actually skip over the unrecognized part.  This
> happens to be OK for the MPEG4 decoder, but results in some leading garbage
> in the output (it assumes a gray reference frame).  It would be nice if it
> were possible for typefind to also indicate an offset at which it detected
> the type found, and give the application the option to skip over leading
> garbage.  That would be a major overhaul, though...

That's a bug in the MPEG-4 decoder - it should drop data until it gets
a keyframe (although an optional mode to do what it's currently doing
might be good for some uses).

Mike

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel