[mythtv] Need help diagnosing slow XvMC problem

[Jerry Rubinow]

On 1/14/06, Jerry Rubinow <jerrymr at gmail.com> wrote:
> > -----Original Message-----
> > From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org]
> > On Behalf Of Jerry Rubinow
> > Sent: Tuesday, January 10, 2006 5:10 PM
> > To: mythtv-dev at mythtv.org
> > Subject: [mythtv] Need help diagnosing slow XvMC problem
> >
> > When I play back content using XvMC, it plays back slower than real
> > time, both HD and SD, cpu is not maxed out.  I haven't been able to
> > figure out why, but it seems like it might be a Myth problem (but
> > maybe not?).
> >
> > Here's what I have:
> >
> > Separate front end/back end.  Front end is a 2.8Ghz P4 with a GeForce 5200
> > PCI.
> > Running FC4 setup per Jarod's guide.
> > Myth SVN as of about a week ago.
> > Nvidia driver version 7667.
> >
> > Here's what I've tried:
> >
> > Tried with and without OpenGL sync.
> > Tried Various Nvidia drivers up the the current 81xx.
> > Tried playing same video files over nfs using mplayer with xvmc and
> > they have no problem, so that seems to eliminate disk, network, or
> > graphics card bandwidth problems.
> > No deinterlacing going on.
> >
> > When it plays inside myth, everything is slow-mo.  Not a stuttering
> > problem.  CPU usage is down below 20%.  If I turn off XvMC, SD plays
> > back fine, but HD maxes out the CPU.  However, I hadn't been
> > optimizing for P4 (d'oh), so that can probably be improved somewhat.
> > But if I could get the XvMC thing working that would be a much better
> > solution, since I'd have room to spare for deinterlacing and whatnot.
> >
> > All suggestions welcome.  I'll post whatever logs would be most
> > helpful to diagnose this, just let me know which ones.
> >
> > -Jerry
>
> On 1/14/06, Rob R <rob.r at plutohome.com> wrote:
> > What does the console output/frontend log show while it's playing in slow
> > mo?
> >
> > I get that exact behavior when "extra audio buffering" is disabled.   My log
> > shows a ton of "prebuffering pauses".  With extra audio buffering enabled,
> > it works correctly *most* of the time but I haven't been able to totally
> > solve it.
>
> Good suggestion.  I tried that and the problem got somewhat better,
> but the video is still a little slow and sound is choppy.  When I do
> mplayer -vo xvmc -vc ffmpeg12mc on the same mpeg file, it play back
> absolutely perfectly, video and sound.
>
> My current playback settings are
> -no deinterlacing
> -standard xvmc decoder
> -enable opengl vsync for timing
> -enable realtime priority threads
> -extra audio buffering (problem is worse without this)
>
> Myth svn, version 0.19.20051208-1
>
> Enclosed is the frontend output from -v all,nodatabase.  Things that
> look like they might be prolems to my untrained eye (but maybe they're
> ok):
>
> -VideoOutputXv Error: Couldn't get the color key color
> -lots and lots of "Broadcasting free space avail" messages
> -nVideoVideoSync: VBlank ioctl did not work, unimplemented in driver?
> -DRMVideoSync: Could not open device /dev/dri/card0, No such file or directory
> -a bunch of NVP: Video is X.XXXXX frames ahead of audio, skipping A/V wait.
> -a bunch of audio waiting for buffer to fill: have 2048 want 4096
> -a bunch of NVP: prebuffering pause
>
> CPU is around 40%

I finally made some progress.  I was looking at settings on other
pages, and noticed Ringbuffer, which I probably should have tried
earlier but I didn't think of it.  So I doubled the ringbuffer size
from the default and it started playing back perfectly with XvMC!  If
I switch to libmpeg2, it plays back in realtime, but the motion isn't
smooth and sound is choppy.

If I encounter no further problems with XvMC, I won't worry about it,
although previously the picture would occasionally freeze on start of
playback (although I could still ESCape out back to the menu and
retry, at which point it would play ok).

Where does the ringbuffer live - frontend or backend?  What is a
likely reason that increasing the ringbuffer size solved my problem? 
I guess it was a bandwidth issue somewhere.  But mplayer did not have
a problem playing mpegs that lived on the backend.  And what reasons
might there be that ibmpeg2 would still not work (doesn't seem to be a
CPU problems - usage was only around 40%?

-Jerry