[Mesa-dev] [PATCH 1/9] st/vdpau: fix chroma_format handling in VideoSurfaceQueryGetPutBitsYCbCrCapabilities
deathsimple at vodafone.de
Fri Mar 9 04:21:33 PST 2012
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
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
> 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
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 -
> 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.
More information about the mesa-dev