[mythtv] Re: XvMC and Mythtv

Daniel Kristjansson danielk at cat.nyu.edu
Sat May 14 21:51:51 UTC 2005

On Sat, 2005-05-14 at 22:07 +0800, David Shirley wrote:
> hey daniel,
> i did some more diagnosis... this is with today's CVS...
> I found that when watching 1080i TV the CPU will sit at 30% for credits
> (ie mostly black screen), and 50-60% for normal TV.

This is pretty high, I'm thinking maybe the Athlon XP @ 2Ghz isn't
up to decoding 1080i with 8 buffers, even with XvMC. The only thing
I can suggest is try enabling real-time threads by setting the suid
bit on the MythFrontend executable.

The problem his that while it is "only" eating up 60% of your CPU
MythTV needs the CPU in a bursty fashion in order to get frames
queued up and displayed in time.

Having eight XvMC buffers really means you only have two free buffers
in the worst case scenario. Two for OSD, three for I/P-frame past/future
frames, one for display, and _two_ for filling. If there is a lot
of motion or some other process is sucking up the CPU when one of
those two frames becomes available, then you get problems... And
this "worst case scenario" happens all the time with XvMC. You
have basically 1/30th of a second (@720p), to fill two buffers,
and you must do it at a rate of 1 buffer every 1/60th of a second.
Which means you are really using the fancy soft real-time features
of the 2.6 kernel just to keep up. This means you can't have any
non-preemptable drivers, your APIC interrupt situation has to
be happy, your hard-drive DMA access must be working properly,
and your driver must unmask interrupts (hdparm -u). It's just to
much to expect to go right.

I'm hoping that if enough people complain to nVidia about their
XvMC implementation only having eight buffers they will fix this
in a future driver... The VIA Unichrome drivers support twice as
many buffers!

-- Daniel

More information about the mythtv-dev mailing list