VDPAU performance with an Asus AT3N7A-I

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]<

 



On Mon, 2009-12-21 at 23:50 +0100, Richard Hartmann wrote:
> On Mon, Dec 21, 2009 at 23:28, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > Well it's kind of hard to say anything when the only information about
> > the problem is "far from smooth".
> 
> I am more than happy to give you any and all information you need,
> you just need to tell me what you do and how to get it :)

You said that playback "gets choppy when a lot of detail is in the
video", but also "playback is far from smooth". So is it isolated cases
of "choppiness", or are there constant problems?


> > Does the A-V value shown on the status
> > line stay at 0?
> 
> It is between 0.000 and -0.001.

And it stays there also during any particularly "choppy" parts?


> > Does the VDPAU benchmark result change if you use "-vo
> > vdpau:fps=-1"?
> 
> Gut feeling is no, see below for the benchmark for
> 
>   -vo vdpau:fps=-1 -vc ffh264vdpau -fs

You could also check that this makes no difference for the A-V value
during any "choppy" parts - the sync/drop behavior could perhaps make
the effect of individual particularly slow to decode frames less
apparent on the status line by allowing faster recovery.

I'm not sure what else to check. If the choppiness really does depend on
there being "a lot of detail in the video" then that points to some kind
of a performance problem; but OTOH I'd expect a decoding performance
problem to be visible in MPlayer's A-V value, and it staying around
+-0.001 means that to MPlayer it looks like things are happening fast
enough. Another possibility is some VDPAU driver problem. Make sure
you're using the overlay rather than blit queue of VDPAU if possible.
The main reason VDPAU would fall back to the blit version if is you have
the composite extension enabled in X (even if you're not running a
compositing window manager). One simple way to check which one is being
used is to suspend MPlayer with ctrl-Z (so it can't redraw its window)
and then move another window over MPlayer's output window. If the window
contents stay intact then it's the overlay queue; if they're lost when
hidden from view then it's the blit version.



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux