[MPlayer-users] Very slow play with gl default

[Kevin DeKorte]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/27/2010 10:45 AM, Reimar Döffinger wrote:
> On Sat, Feb 27, 2010 at 10:42:51AM -0700, Kevin DeKorte wrote:
>> On 02/27/2010 10:26 AM, Reimar Döffinger wrote:
>>>> *** glibc detected *** mplayer: double free or corruption (out):
>>>> 0x0a5c3f60 ***
>>>> ======= Backtrace: =========
>>>> /lib/libc.so.6[0x376751]
>>>> /usr/lib/dri/r600_dri.so(+0x13482)[0xf692c482]
>>>> /usr/lib/dri/r600_dri.so(+0x21370)[0xf693a370]
>>>> /usr/lib/dri/r600_dri.so(+0xfcb3a)[0xf6a15b3a]
>>>> mplayer(glSetupYUVConversion+0xcbc)[0x80a6368]
>>>> [0x2]
>>>
>>> Looks like a bug in the fragment program compiler or something like that
>>> to me (well, using mesa git you can hardly complain about bugs...).
>>> I'd suggest trying -vo gl:yuv=0 - it should at least give you hardware scaling
>>> and subtitle blending for free over x11 (though xv is probably still a better choice).
>>

With the :yuv=0 option to gl I still get the BadMatch, the video does
actually work and mplayer doesn't segfault. So that means a shader
error? If so I'll open a bug on the radeon driver with a test case.

>> I think there might be a bug in mplayer as mplayer from the command line
>> with -vo gl works fine, only fails when combined with the -wid option.
>> So maybe that is why the BadMatch is emitted.
> 
> Well, it's possible. Or maybe the radeon driver can't handle rendering into
> a window owned by a different process...

Then why does gl2 work fine? I will keep updating mesa and let you know
if the problem gets fixed there.

Kevin
- -- 
Get my public GnuPG key from
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuJXPQACgkQ6w2kMH0L1dG9LACePXU5GKOrm1KPzXfqxUdxMoed
yhIAnjP1c9KqvudjkYgabM97QMACJRlA
=06+W
-----END PGP SIGNATURE-----