On Sat, Feb 27, 2010 at 09:48:45AM -0700, Kevin DeKorte wrote: > On 02/27/2010 09:34 AM, Reimar D?ffinger wrote: > > On Sat, Feb 27, 2010 at 05:16:12PM +0100, Etienne Buira wrote: > >> r30759 plays some "normal" video files (25 fps) at around 1 fps when using > >> gl as default output (why that default?). > > > > Well, because x11 is bad, always and no exceptions. > > gl either is really good or makes it really obvious that something is wrong. > > My impression was that a lot of people end up using x11 because the forgot > > to install the xv headers. > > I'd like to void defaulting to OpenGL when software rendering is in use, > > however I don't know for sure how to detect that reliably. > > Could you send the output of glxinfo on your machine? > > I actually disagree that x11 is always bad, at least you get a picture > with it, it may have tearing or other wierdness, but at least it works. x11 is always bad for video IMO. It may be the best available and it is useful, but that does not make it not bad. > using mplayer gl output when combined with gnome-mplayer. mplayer will > crash using SVN r30759. x11, xv and gl2 all work fine. I am using mesa > from git. > > (chopped output, if you want a full backtrace I will be happy to send it) > > ERROR: X11 error: BadMatch (invalid parameter attributes) > ERROR: Failed to get value of property 'sub_demux'. Those are very strange, though I guess unrelated. > *** 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).
