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

Joakim Plate elupus at ecce.se
Mon Dec 16 23:58:42 CET 2013


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.


On Mon, Dec 16, 2013 at 9:54 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> Joakim Plate <elupus <at> ecce.se> writes:
>
> > Current code would end up providing invalid timestamps
> > if always run with NONREF since has_b_frames would be
> > setup wrongly, so calculated dts from pts would be wrong.
>
> I just tested transcoding with -skip_frame noref and the
> resulting file played in-sync. But that probably wasn't
> what you meant?
>
> > Also, having AVDISCARD_ALL be less discarding than
> > NONREF seem a bit strange.
>
> I don't disagree but I think making a feature slower
> which is only there to speed decoding up is not ideal.
>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list