On 08.03.2012 20:12, Andy Furniss wrote:
Christian König wrote:
mplayer sw decode + yuy2 vdpau output is corrupted.
Yeah, still working on that. The problem is tilling related, just
disable 2D tilling and it works like a charm. I think I've found the
problem right now and going to send out some fixed patches in the next
couple of minutes.
Working OK for me now with xine and mplayer using your vlwork git,
which I assume is the same as applying the latest patches.
Yeah it is, I started to push my patches there cause somebody asked for
a git tree instead of patches.
Is there a way to disable mesa 2D tiling anymore? I know about the
xorg.conf options but they don't seem to affect mesa.
Not without hacking the code, the xorg.conf options only affects the
tilling of buffers the DDX allocates, e.g. the front/back buffers of
drawables.
But hacking the code a bit is actually quite easy, cause there is a
central function (r600_texture_create) in r600_texture.c that controls
which tiling gets used for a resource, just set array_mode to zero and
you disabled all tilling.
Unfortunately mplayer just doesn't tries to use a planar 422 format
(something which is really easy to support).
I think mplayer's vdpau was written by nvidia, so maybe it assumes
things - but then I don't know that. I do know it blindly tries to use
yuy2 even if it's not advertised.
Indeed, mplayer isn't checking any feature it is using, but apart from
that the implementation looks quite sane (compared to what is xine doing
for example).
One thing I noticed looking at the vdpau spec on their doxygen site is
that YUY16 isn't even listed.
When -vo gl is used mplayer will directly use 422 planar (which I
assume is what fourcc.org calles YV16).
VDPAU just calls everything planar either YV12 or NV12 and has a
separate chroma-format parameter, and from their OpenGL <-> VDPAU
implementation it looks like that 422 is just handled planar internally
also. So what mplayer does with its 422 implementation is converting it
from YV16 -> YUYV and the nvidias VDPAU implementation just converts
that back from YUYV -> YV16 with a shader.
As for xine my current issues are the logo, mine is playing
share/xine/skins/xine-ui_logo.png with plugin gdkpixbuf
Before 422 worked properly it was distorted, now it's almost OK, but
has a green band at the bottom. If I toggle between full screen and
window a few times I can get it to crash - bt attached.
It works OK with xv, and actually playing a raw 422 yuy2 stream with
xine + vdpau looks OK and won't crash toggling (it is different size
though).
That strongly depends on the codec used, unfortunately VDPAU has no way
of advertising (for example) support for MPEG2 420, but not MPEG2 422....
Anyway, it's still an improvement over the current status quo, so I just
pushed the patches upstream.
Issue 2 is that doing something that makes xine try to render over the
video eg. skipping or changing volume results in an assert -
vl/vl_video_buffer.c:320:vl_video_buffer_sampler_view_components:
Assertion `component < 3' failed.
bt also attached.
Yeah, and there are some additional issues that xine sometimes jumps in
the middle of a frame while seeking, tries to set the internal format of
video surfaces BEFORE decoding, accessing VDPAUs drawable (while the
VDPAU documentation clearly states NOT to do so).....
I really start wondering if it wouldn't be better to fix xine, instead
of shifting the implementation to a point where it actually works
flawlessly with that player.
Anyway, I will be busy with UVD code review next week so I won't have
time to work on the state tracker for some time now, so that has to wait
for a little while longer.
Thanks,
Christian.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
