[mythtv] EPIA M10k - XvMC: Very high CPU (even when paused!!)

[Colin Guthrie]

Daniel Kristjansson wrote:
>> As I tried to diagnose further, it seems to now (annoyingly, but nicely)
>> pick MPEG2VIDEO_XVMC_VLD more consistantly.
>>
>> I don't really know what I did to fix this, but for the moment I'll keep
>> quiet and hope for the best :)
> 
> There is a function in videoout_xv.cpp called
> GetBestSupportedCodec(), this checks if it is possible to
> use any video acceleration which has been configured. This
> checks a few things: First, the video must use a supported
> codec, either MPEG-2 or MPEG-1 for OpenChrome. Second, it
> must be possible to allocate a video frame of the desired
> size (some video accelerators only with with PAL/NTSC
> resolutions and not with HDTV). Third, a XVideo port with
> the required capabilities must be available.
> 
> The last requirement can become a problem. If MythTV or
> another application that uses XVideo crashes it may leak the
> XVideo port we need. This is due to a mistake the people who
> wrote the XVideo specification made. They didn't allocate
> device nodes in "/dev" for the ports, so Linux and other UNIX
> like kernels can't clean up properly after a crash; the
> application has to do it, and sometimes it can't. When this
> happens the only solution is to exit Xorg and unload and then
> reload the video output driver module. I don't know if this
> works with OpenChrome, but this works with the nVidia drivers.

Thanks for the explaination, it helps me understand a little better now
and presumably is the reason that I usually see a plain MPEG2VIDEO propr
to the MPEG2VIDEO_XVMC_VLD, as I am guessing that it uses the former to
gauge if the latter would work. Or I suppose the preview video could be
causing the MPEG2VIDEO log entry.

Or perhaps both are true, in that the preview video does cause /a/
MPEG2VIDEO log entry but when starting playback it also causes another
(initial) MPEG2VIDEO entry as it does it's detection. I think this last
one is correct (by observation of a few "play program xxx yyy" and "jump
playbackbox" network commands!

Also as I typically do not reboot, but suspend, this clarifies why it
can be that I need to reboot to get rid of jerky video (I say I /need/
to reboot but an Xorg reload and/or driver unload would probably be
sufficient judging by your explaination). !!!This may not be correct!!!
Read on.......

>> I had the same recording using MPEG2VIDEO and
>> MPEG2VIDEO_XVMC_VLD on two successive "plays".

> Hmmm, that sounds odd; nothing else played video in-between?

Certainly my current boot is only permitting MPEG2VIDEO. But then I used
network control to play again the same video as was currently playing
and it started using MPEG2VIDEO_XVMC_VLD. The last time I got it working
after it refused was due when I used network control also and just jump
straight from one recording to another.

VERY INTERESTING. When I use the newtwork control it always initialises
the MPEG2VIDEO_XVMC_VLD, but when I use the keyboard on the frontend, it
doesn't. I think this must be related to how the preview video from the
playbackbox is cleared when the options dialog and/or the optional "play
from" dialog are displayed/closed.

I'm guessing that Myth itself is not clearing out the Xvideo port
quickly enough (or at all?). This explains why I couldn't get it to work
with MPEG2VIDEO again as I was using network control to restart
playback. It's all falling into place :)

Having now done more reasearch while writing this email, the preview
video does always use MPEG2VIDEO output, rather than select
MPEG2VIDEO_XVMC_VLD. Not sure if this is deliberate or required for the
scaling.

Playing the preview video does take up a huge amount of my CPU: ~60-80%
which is considerably more than the ~10-15% I get for actually playing
the video full screen with VLD!

WDYT? I don't know that code very well, but perhaps the playback
initialisation needs to wait for a semaphore of some kind before
starting the full screen playback?

I've not got the CPU friendly previews option on, but I'll try that now
and let you know if it has the same behaviour.

Col.

-- 

+------------------------+
|     Colin Guthrie      |
+------------------------+
| myth(at)colin.guthr.ie |
| http://colin.guthr.ie/ |
+------------------------+