[MPlayer-dev-eng] Video CPU usage reported incorrectly since 33114 threading patch

[Reimar Döffinger]

On Wed, Mar 30, 2011 at 04:26:24AM -0700, Hermi Mercury wrote:
> I noticed that when multiple threads are used with mplayer revision 33114
> (through r33148), the video CPU usage reported is near 0%, as compared to
> ~20% for revision 33113 of mplayer.  The changes introduced in r33114 enable
> threading (for the ffh264 video decoder at least).

CPU usage was never meant to be comparable to e.g. top, for example running
a second program at the same time would increase CPU usage and similar things.
The point of the CPU usage number is to indicate how much headroom there is.
More precisely, it says how much of the time available to process the frame
was spent on waiting for decoding.
Since with frame-level multithreading data is decoded ahead and e.g. in parallel
while we are waiting for vsync or just sleeping we often don't have to wait at all.
I admit that this currently is a bit too extreme and will result in 0% even
when we are already somewhat close to the limit, but I don't really have
any much better idea.
The actual CPU usage doesn't seem that useful, both because you can get that
via e.g. top and because it doesn't really answer whether there's an issue
decoding the video fast enough.
Currently, even with -mt, 100% usage means "we don't manage to decode in time",
and anything else means we do, and I'd like to keep that that way.