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

[Emeric Grange]

2012/3/9 Christian König <deathsimple at vodafone.de>
>
> 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.


I confirm that with the latest round of upstream patches :
- Xine is working a bit better (at least it is not segfaulting anymore
while starting up)
- My 4:2:2 mpeg2 sample is now working great with -vo vdpau

Regards,
Emeric