Video CPU usage reported incorrectly since 33114 threading patch
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). Some output from testing indicates that because thread_count was not being set in r33113 (when using pthreads at least), threading was not enabled with this earlier build. I tracked CPU usage reporting down to the video_time_usage variable, where it is incremented in dec_video.c, but was unable to determine exactly how threading was interfering with this counter. If someone with some more experience in this area could take a look I'd appreciate it. Regards, - Hermi
ons 2011-03-30 klockan 04:26 -0700 skrev Hermi Mercury:
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).
Some output from testing indicates that because thread_count was not being set in r33113 (when using pthreads at least), threading was not enabled with this earlier build. I tracked CPU usage reporting down to the video_time_usage variable, where it is incremented in dec_video.c, but was unable to determine exactly how threading was interfering with this counter.
If someone with some more experience in this area could take a look I'd appreciate it.
From what I know it is not CPU time but real time that is measured. By using threads or GPU decoding, real time spent for each step goes down.
For example, when I used vdpau for decoding and display, I get zero time used for video decode and display. Only audio handling still produces time. Dan
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.
participants (3)
-
Dan Oscarsson -
Hermi Mercury -
Reimar Döffinger