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

[zhangfei gao]

Jan,
   
  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?
   
  Thanks
   
   
   
  
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:

*snip*

> 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.

Regards,
Jan.





       
---------------------------------
抢注雅虎免费邮箱3.5G容量，20M附件！ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20070523/b7624180/attachment.htm>