[mythtv-users] HD live tv stuttering
Tim Coote
tim+mythtv.org at coote.org
Thu May 27 09:33:53 UTC 2010
Hullo
As much as anything, this is an observation, and a plea for some
pointers on how to unpick some of the complexities of mythtv.
I've just built a system with the frontend on an acer revo 3610, using
its hdmi interface. Using VDPAU, this has a low cpu usage (~20% on one
cpu, compared to >120% and stuttering when using software decoding),
but it can be quite slow to respond. I find it near impossible to
isolate any cause of slow response - that's a simple example of the
type complexity that I'd like to unpick: where can I find a high level
description of the moving parts, how they interact and the resources
that they use/constraints on performance?
fwiw, I based my build on fedora 12 and spent some time faffing with
pulseaudio, before throwing it out completely. There were a couple of
issues here to do with effectively testing the hdmi (as far as I can
see, the standard is not implemented consistently, and I naively
assumed that surely my newish tv was working), and then actually
driving the alsa's tools talking to pulseaudio, which then drives the
alsa drivers. Even when I ripped out PA, I still had what I consider
odd behaviour from alsa: speaker-test not only requires root
privileges, but wouldn't work until I'd run up a gnome destkop (??)
The myth specific point: I was having some stutter on bbc hd with the
vdpau drivers. Lots of prebuffering pauses on the output, even when I
stripped the playback profile to a minimum. However, it turned out
that the stutter / prebuffering may be down to running mythfrontend on
the command line and letting it spit its output onto the terminal:
merely redirecting the output to capture it stopped the prebuffering.
Is this behaviour (mythtv behaviour differing depending on where
stdout points) as expected?
Is there a reference guide for the output from the various components
to understand what's an issue or not? Mythtv seems to do a lot of
trying to recover from known environmental problems. Although this can
get simple configurations up and running faster, it does contravene
the engineering principle found in high availability systems of 'fail
fast', and means that underlying problems are masked, making debugging
more complex set ups much harder to get right.
Tim
More information about the mythtv-users
mailing list