[FFmpeg-devel] [PATCH 1/1] h264: remove skip of h264 parsing independent of skip_frame

Michael Niedermayer michaelni at gmx.at
Tue Dec 17 00:50:42 CET 2013

On Mon, Dec 16, 2013 at 11:58:42PM +0100, Joakim Plate wrote:
> I suspect if you set it by commandline it still won't take effect until
> after find_stream_info. For most streams at that point the delay has been
> guessed already. For a live stream that might not be the case.
> It would still play in sync thou. The issue would be dts vs pts. Depending
> on if you have a valid has_b_frames the diff between the two might vary.
> The need for this and it's parent patch is mainly for very low end systems
> with hw accel. On those when we end up decoding h264 in software for
> several frames at the start of a stream, we get a very poor startup
> performance.
> I suppose a "parse only" flag for codecs could do the trick too. But this
> seem like the best approach. In xbmc case anyway the only time we set
> discard normally is when we fastforward or need to hurry up.
> I suppose we should do some real measurements on the actual performance
> loss. I might very well be completely lost in other things.

if neccesary, it would also be possible to make the discarding
behavior dependant on if the frame reordering delay has been
sufficiently estimated

so the slowdown (if there is one) would only affect the first few
This would avoid the need for a new flag or option

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131217/14ea3d65/attachment.asc>

More information about the ffmpeg-devel mailing list