[FFmpeg-devel] high cpu usage and frame dropping

[Reimar Döffinger]

On Wed, May 02, 2012 at 04:08:34PM -0400, Don Moir wrote:
> >I don't think you can have tested many. MPlayer will just desync, or you
> >can tell it to skip even decoding, though that has a good chance of
> >crashing.
> >Anyway I can't see why it is a sad state, in 90% of cases the video will
> >be unwatchable anyway, why putting a lot of effort into what just ends
> >up prolonging the users' pain.
> 
> I tested WMP, QuickTime, VLC, SMPlayer, and player built into
> firefox. I would say the most used players on windows are WMP,
> QuickTime, and VLC. SMPlayer uses mplayer.

If SMPlayer behaves that way it overrides MPlayer's defaults with worse
ones.
It probably uses -framedrop. Which was designed and implemented in a
time where converting to RGB and pushing through the X server and to the
video card had a good chance of being a lot more expensive than
decoding.
With heavy deinterlacing that actually still has a good chance of being
true, in which case your approach might needlessly degrade playback
quality.

> >>I have tried various flags etc to speed things up and that helps
> >>a little but not enough and they don't really work anyway. There
> >>could be something in the flags or callbacks that would help
> >>alot but I have not found them yet.
> >
> >You're too vague. skiploopfilter always helps a lot for files using the
> >feature.
> >For high level H.264 skipping nonref frames will cut the processing time
> >by at least half.
> 
> I have tried skip_frame and skip_loop_filter. These do help. The
> thing is you need to turn these on and off on the fly depending on
> CPU usage etc. and that is ok but still in some cases not enough.

I can see that they just will not work in some cases.
But ignoring these, if skipping at least half the frames does not
help I have a hard time imagining in which case anyone would want
to watch the result at all.

> Also, you can't use these blindly as you may not get any frame at
> all depending on demuxer

What would the demuxer have to do with that? Those are decoder options,
the demuxer should not even be able to know in any way that you are
using them.

> I think using skip_frame and skip_loop_filter can have some side
> effects such as distortion also, when changing on the fly, so that
> has to be dealt with.

Not with NONREF, no, never (bugs excluded).

> Is there any possible way to know if a future keyframe will exist on
> a general basis when index entries may not exist ? If it means I
> have to look as every possible codec and make a best guess that
> would probably be ok.

All non-bitexact codecs (basically anything before H.264) needs a
keyframe at least around every 100 frames or the output will start
to differ significantly between different decoder implementations.