[MPlayer-dev-eng] Video output for RV280+Mesa3D

[malc]

On Sat, 6 Dec 2008, Reimar D?ffinger wrote:

> On Sat, Dec 06, 2008 at 02:29:18AM +0300, malc wrote:
>> On Fri, 5 Dec 2008, Reimar D?ffinger wrote:
>>
>>> On Fri, Dec 05, 2008 at 10:01:02PM +0300, malc wrote:
>>>> It also printed:
>>>>
>>>> [swscaler @ 0x106a5b50]ALTIVEC: Color Space BGR24
>>>> [swscaler @ 0x106a5b50]using unscaled yuv420p -> bgr24 special converter
>>>
>>> Ok, that obviously went very wrong. How about
>>> -vf format=yuy2 -vo gl:ycbcr:mesa-buffer:rectangle=1:force-pbo -dr
>>> except for your optimized conversion to yuy2 it should behave very
>>> similar to your code (needs the current SVN version of vo_gl).
>>
>> It does work (save for swapped u/v values, nothing a one liner patch
>> cures though) and the picture is okay. Speed isn't there though:
>>
>> BENCHMARKs: VC:  14.855s VO:  14.168s A:   0.000s Sys:   0.167s =   29.190s
>
> Hm, colours are right here on i945.

Erm.. i945 on x86. I've rv280 on ppc. So it's host endianness issue
really.

> Probably libswscale is broken. It would be really interesting to know
> _what_ part of your code makes it faster, though I suspect that swscale
> is what causes most of it...

I'm pretty sure i know which part makes it THAT much faster, r200 dri
driver (i think i915 too) requires the stride to be multiple of 64 to
have zero copy texture uploads, something you don't know till you digg
into the Mesa sources. Having custom yuyv->yv12 converter helps some
too, but not nearly as much.

>
>> (vo_rv280 does it in 16secs)
>
> Hm, does it enable vsync? I guess for benchmarking you should probably
> better use
> -vf format=yuy2 -vo gl:ycbcr:mesa-buffer:rectangle=1:force-pbo:swapinterval=0 -dr
> to disable vsync.

That did improve the timing by ~2 seconds.

-- 
mailto:av1474 at comtv.ru