[Mesa-dev] [PATCH 1/9] st/vdpau: fix chroma_format handling in VideoSurfaceQueryGetPutBitsYCbCrCapabilities

[Christian König]

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.