<div>Jan</div> <div> </div> <div>thanks for your big help.</div> <div> </div> <div>I still have one question about fps, excuse me for bothing you so much</div> <div> </div> <div>In sinkpad_setcaps function it only send such information.</div> <div> </div> <div>name: video/mpeg<BR>video/mpeg, mpegversion=(int)2, systemstream=(boolean)false</div> <div> </div> <div>Should we calculate fps from es data?</div> <div> </div> <div>Thanks<BR><BR><B><I>Jan Schmidt <thaytan@noraisin.net></I></B> дµÀ£º</div> <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">zhangfei gao wrote:<BR>> Jan,<BR>> <BR>> Thank you very much for your kind notification.<BR>> <BR>> Now I use repack, I could know there is a frame only if data is inside<BR>> two sync code.<BR>> The problem is if input buffer is really one frame, I could not get the<BR>> correct answer immediately, except
next sync code is got, so memcpy is<BR>> unavoidable.<BR><BR>If the video packets have been split when they were muxed, then at least<BR>one memcpy to reconstruct them is unavoidable.<BR><BR>Other than that, I'm not sure exactly what you're trying to ask here.<BR><BR>> what about mpegvideoparse reaction when input buffer is really one<BR>> frame, does it need another sync code, which means memcpy.<BR><BR>Detecting the start of the next picture packet requires scanning for<BR>another start code, yes. mpegvideoparse does this without performing<BR>more memcpys that necessary, but at least one is required to reconstruct<BR>non-contiguous packets into a single buffer for decoding.<BR><BR>> If so, maybe set repack function to mpeg2dec plugin will have better<BR>> performance, since context switching time is saved.<BR><BR>I don't know what you are trying to say here.<BR><BR>Regards,<BR>Jan.<BR><BR><BR><BR><BR></BLOCKQUOTE><BR><p> 
<hr size=1><a href="http://cn.mail.yahoo.com" target=blank>ÇÀ×¢ÑÅ»¢Ãâ·ÑÓÊÏä3.5GÈÝÁ¿£¬20M¸½¼þ£¡</a>