[FFmpeg-devel] high cpu usage and frame dropping
donmoir at comcast.net
Wed May 2 23:48:40 CEST 2012
> 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
>> >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
> 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
> With heavy deinterlacing that actually still has a good chance of being
> true, in which case your approach might needlessly degrade playback
>> >>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
>> >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.
I can agree with that if all you want to do is watch a video and the app is
only a video player. In some of the apps that will be using my av library it
will not only be playing videos but also doing laser output among other
things. I need to be able to cover my ass so that the av library is not the
point of contention. Natually we expect the end user to have a capable
machine buts its not always the case. Also spikes in CPU usage can be short
lived and no reason to fall apart because of it.
>> 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.
Yes the decoder.
>> 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).
Ok good to know when i get back to that. It may be usage of NONKEY but I
will know more later.
>> 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.
Thanks for your input.
More information about the ffmpeg-devel