[gst-devel] re: Re: flupsdemux: how use flupsdemux handle D1 size stream

zhangfei gao gaozhangfei at yahoo.com.cn
Wed May 23 06:11:17 CEST 2007

  Thank you very much for your kind notification.
  Now I use repack, I could know there is a frame only if data is inside two sync code. 
  The problem is if input buffer is really one frame, I could not get the correct answer immediately, except next sync code is got, so memcpy is unavoidable.
  what about mpegvideoparse reaction when input buffer is really one frame, does it need another sync code, which means memcpy.
  If so, maybe set repack function to mpeg2dec plugin will have better performance, since context switching time is saved.
  Could you give some ideas?
Jan Schmidt <thaytan at noraisin.net> 写道:
  zhangfei gao wrote:
> Hi, 
> I use flupsdemux handle 704x480 size video, it seems flupsdemux do not
> send integrated frames.
> It will go to mpeg2dec 6 times, print info as below:


> But when I demux some small size, the input frame is intact.
> Is there any method to judge whether the input frame is intact or not,
> since our codec only handle intact frames.

The data is delivered from the demuxer according to the packetisation
that the muxer gave it. This usually does not coincide with elementary
stream video boundaries. If your codec cannot parse the stream to find
the picture boundaries itself, I suggest you use the mpegvideoparse
element between the demuxer and the decoder.

You can either insert mpegvideoparse in the pipeline manually, or
specify 'parsed=true' as a requirement on your decoder element sink pad,
to cause it to be autoplugged if you are using decodebin/playbin.

mpegvideoparse is available from CVS of gst-plugins-bad, and will be in
the 0.10.5 release in a week or so.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20070523/b7624180/attachment.htm>

More information about the gstreamer-devel mailing list