[FFmpeg-devel] high cpu usage and frame dropping

[Don Moir]

> 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.

Ok.

>
>> >>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.
>

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.