Created attachment 39222 [details]
gl:yuv=3.jpg

normal picture

Created attachment 39223 [details]
gl:yuv=4,lscale=1,cscale=1.jpg

bad picture

tested commit 469907d59738ad32c7a3b95072897432f1e81a0f with kernel 2.6.36 and "ColorTiling"="on".
same thing :(

tested without 'lscale=1,cscale=1' and it makes no difference. setting 'yuv=4' triggers bug alright.
but specifying 'yuv=1' and '5' (register combiners/GL_NV_register_combiners and GL_ATI_fragment_shader) also gives colorless picture and it's much darker.

i will use method '6' for now with hope that it's not really "Extremely slow (software emulation) on some (all?) ATI cards since it uses a texture with border pixels" as mplayer's manual says.

Created attachment 42092 [details]
gl:yuv=6 - broken output.jpg

recently method '6' was broken and i have to fallback on method '2'.

every video in mplayer with yuv=6 looks like green thing on picture plus some changing random artefacts while video playing. were even were some git revision with which any gl output was broken that way (or at least mplayer with -vo gl and warzone2100 game) but it's ok now. only yuv=6 output with mplayer is broken.
yuv=4 glitching the same way as before and have no colors.

there also were a glitch with yuv=6 when it still worked: bright whitish places in videos were just plain white but this may be mplayer bug since i have never tested it on some other hardware or non-open drivers.

Works any better now ?

yes, thanks. the green thing is gone with yuv=6 but
1) yuv=4 on r600g still have no colours even though with r300g they are ok
2) still there is an overbright glitch in some white places in some videos with yuv=6. but again, it may be a mplayer bug since it present with r300g too (but not software rasterizer), i'm not sure.

so, it's back to beginning.

(In reply to comment #6)

> 1) yuv=4 on r600g still have no colours even though with r300g they are ok

yuv=4 with or without bicubic now works for me on 600g

> 2) still there is an overbright glitch in some white places in some videos with
> yuv=6. but again, it may be a mplayer bug since it present with r300g too (but
> not software rasterizer), i'm not sure.

This is still the same.

One general observation is the with 600g perf is poor compared to 600c or xv, which are at least 2x faster when benchmarking with HD streams.

same here.
and i never got answer about which method is better with amd/ati card and open stack now. i hope devs are looking into that stuff.

(In reply to comment #8)
> same here.
> and i never got answer about which method is better with amd/ati card and open
> stack now. i hope devs are looking into that stuff.

Maybe there isn't an answer as such for that question.

I guess someone with an on-board low spec GPU may be more limited than a high end card with fast vram.

Quality wise - I can't see any difference, the higher yuv= numbers give more features like gamma correction (not sure how to use it though).

It would be nice if 600g could beat or equal 600c - it does for 3D, but for some reason not this.

I said classic was twice as fast - it's actually more than that if I discount time taken by the codec.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/391.