2012/3/9 Christian König <deathsim...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
