On Mit, 2013-02-06 at 12:16 +0100, Rémi Denis-Courmont wrote: > On Wed, 06 Feb 2013 11:18:19 +0100, Michel Dänzer <daen...@debian.org> > wrote: > >> The fact that it works just fine when plain X11 output is forced in the > > >> preferences proves that X11 would work fine, but is not attempted with > >> default > >> settings. > >> > >> In other words, the problem lies with the OpenGL drivers. I have a > >> similar > >> problem on a laptop also with AMD/ATI chip (although mine has XVideo > >> working > >> fine so hardly a problem). This apparent regression is probably due to > >> VLC > >> using shaders for YUV color space conversion since version 2.0.0. > >> > >> I doubt VLC is at fault here, and I fail to see what else it could do. > >> If > >> shaders are so slow, the driver should not offer them in the first > place. > > > > Why do you think the problem is that 'shaders are slow'? > > That's the main difference between OpenGL in VLC 1.1 and VLC 2.0, version > against which the bug was filed. It's also what I'm experiencing with my > own ATI chip.
I doubt the problem is that 'shaders are slow'. In particular, there's no reason why the shaders would suddenly be slower in consecutive frames when they obviously managed to render the first frame quickly. It rather sounds like VLC stops decoding / rendering after the first frame (few frames?) for some reason. Hence my repeated request for isolating if and where VLC is hanging, or what else it is doing when the video output is frozen. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1360159318.23735.236.camel@thor.local
