[mythtv-users] prebuffering pause
fnorbenden at yahoo.com
Tue Jan 6 19:55:24 UTC 2009
----- Original Message ----
From: George Mari <george_mythusers at mari1938.org>
To: Discussion about mythtv <mythtv-users at mythtv.org>
Sent: Monday, January 5, 2009 7:30:52 PM
Subject: Re: [mythtv-users] prebuffering pause
Mike Kurtz wrote:
> I disagree that fixing XvMC will solve the problem. I don't think you
> are CPU-bound. I'm guessing you have something like a P4 or Socket-754
> or Socket-A Athlon? I think you have audio issues, or at least audio
> configuration issues.
> Since you mentioned Pulseaudio, I'm assuming you distro is Fedora?
> If you are using KDE, did you disable the ARTs sound server, as
> recommended in the wiki?
> So what is your %idle from top when playing back? Is the 32% you listed
> before not accurate?
> My strategy to fix problems like this is to temporarily switch to a very
> vanilla, generic configuration. It makes isolating problems much simpler.
> 1. Use Xv for output instead of XvMC. Even if you think you need to
> have XvMC because your system is too slow, just turn it off anyway.
> 2. Turn off all de-interlacing.
> 3. Turn off Pulseaudio and any other sound servers like ArtS.
> 4. Use the recommended ALSA:default for sound output in Myth.
> Start mythfrontend from the command line, and playback a recording,
> preferrably SD. If you're not getting sound with ALSA:default, fix your
> ALSA config.
> If things work OK, turn on de-interlacing. OpenGL Vsync is the
> preferred method of video timing - make sure you see a message in the
> output that this is the video timing method being used.
> Now, if after you have your sound and de-interlacing properly setup, you
> find that you have 0% idle from top during playback, then I would
> start looking into XvMc.
> I'm using SuSE 11 with pulse. I disagree that it is an ALSA problem, because I get the exact same result when I use dsp. There's a couple milliseconds' difference in the log, but it's really the exact same output. I'm using the SB Live!, and that's the one I've changed the latency on.
> Turning off deinterlacing does work, again with the same results using ALSA or dsp. It gives me a clear feed without any stuttering, and there's enough CPU to handle any spikes. With deinterlacing on (even the most basic), I get stutters and CPU spikes where the system idle is at 0-5. OGL vsync is being used in both cases.
> So, it works, but it only works without any sort of deinterlacing, and I doubt I would be able to handle a live stream and a recording simultaneously, and with all the stuff off it still uses most of the CPU, just don't completely starve it. It still has trouble keeping up when the OSD is being removed, even with OSD fade off.
>OK, so what type of CPU are you using? Maybe it's just not up to the
Celeron 356. It's a decently beefy little chip (3.33GHz).
>And am I correct in assuming you are playing back OTA ATSC content? Do
>you notice any difference between playing back SD versus 720P or 1080i?
I am playing OTA ATSC. I think SD playback is choppier, but I can't be certain.
>And did you verify OpenGL Vsync is actually being used, by looking in
>the mythrontend output log?
Using realtime priority.
Video timing method: SGI OpenGL
Seems to be working.
>I also have a vague memory of one of the devs warning about turning on
>OpenGL Vsync in more than one place, and that doing so would cause the
>"sync" be done twice, wasting precious time and slowing down the system.
> I'll see if I can dig up the reference.
I did see one thing I'm not sure of in the output, preceding a prebuffering pause:
[mpeg2video @ 0x7fd5598dad50]00 motion_type at 93 1
[mpeg2video @ 0x7fd5598dad50]Warning MVs not available
NVP: prebuffering pause
Thanks again for all your help.
mythtv-users mailing list
mythtv-users at mythtv.org
More information about the mythtv-users