Videos tearing

[Guilo]

Hi all !

I have just bought an ATI radeon HD3850. I have installed the driver who seems to be loaded correctly.

But when I play videos, I haven't got vsync although I output on gl and have vsync acvtivated in cccle.

Moreover, although fglxinfo tells me I have openGL 2.1, amdcccle says it is openGL 1.2 (1.5 Mesa 6.2.1)

Help would be highly appreciated

Thanks

EDIT : videos are ok when i play on gl or gl2 driver. But HD videos are slow when using these drivers. How to solve this ?

[Zhick]

Xv currently has no vsync with fglrx, so there is no other way than using opengl as output.

[legume]

Hi all !

I have just bought an ATI radeon HD3850. I have installed the driver who seems to be loaded correctly.

But when I play videos, I haven't got vsync although I output on gl and have vsync acvtivated in cccle.

It doesn't work with compiz, which also has it's own vsync but that doesn't work either and using both amdcccle vsync + ccsm vsync + ccsm unredirect fullscreean windows crashed 2/3 times I tried it.

You should get vsync using opengl with mplayer.

Moreover, although fglxinfo tells me I have openGL 2.1, amdcccle says it is openGL 1.2 (1.5 Mesa 6.2.1)

strange I see 1.4 (2.1.7769) with compiz/aiglx and just 2.1.7769 with direct rendering. Not a problem if everything works though.

EDIT : videos are ok when i play on gl or gl2 driver. But HD videos are slow when using these drivers. How to solve this ?

mplayer -vo gl or gl2 does not do yuv>rgb in hardware - just tested on my HD3850 and it's useless - slower than doing it in sw.

mplayer -vo gl:yuv=5,lscale=1

however is only a few percent Cpu usage more than xv.

[Guilo]

Thanks for your replies.

Xv currently has no vsync with fglrx, so there is no other way than using opengl as output

Is AMD planning such a support ?

mplayer -vo gl:yuv=5,lscale=1

still plays slow HD videos.

My CPU is P4 3.2 Ghz. Isn't it possible to use the card capabilities to decode the video ?

Thanks

[RealNC]

Is AMD planning such a support ?

AMD claims the support is already there and has been for a long time now. Maybe AMD's devs are blind or something

[ivanovic]

My CPU is P4 3.2 Ghz. Isn't it possible to use the card capabilities to decode the video ?

No, under Linux there is currently no way to utilize the graphic card for video decoding. That is: With the available acceleration it is just able to handle image scaling but not decoding the video stream. No support for UVD so far, no implementation in CUDA or the like to speed up video decoding. So ATM (might change in some months, who knows...) video decoding is completely done by the CPU.

[Melcar]

AMD claims the support is already there and has been for a long time now. Maybe AMD's devs are blind or something

There is (for my cards at least) no tearing with VideoOverlay + Xine, even if it tends to crash every now and then. My cards using TexturedVideo have horrible tearing, not to mention being unusable with Xine.

[Guilo]

I searched the ubuntu forum and found a solution I will try as soon as I can restart my X :

I?ve found the solution to the first problem (XVideo).

As Jim say in his great post http://forum.compiz-fusion.org/showthread.php?t=6794

The problem is that new ATI drivers set the AVIVO XVideo Render (3D engine) as "default" in Xorg config, instead of older and classic 2D engine XVideo render.
Maybe the avivo (or TexturedVideo) could be better in modern ATI cards (specially to make compiz+videorender compatible), but not seems to has good quality for video in a Xpress 200M. Maybe someone can post some xorg options that solve the "sync problems" specially in movement scenes.

There aren`t aticonfig command to disable this AVIVO config, called "TexturedVideo" option in xorg.conf, so you need to edit /etc/X11/xorg.conf

Option "TexturedVideo" "off"
Option "VideoOverlay" "on"
Option "OpenGLOverlay" "off"

save, and restart de computer, and then test with "xvinfo" and see classic videorender adaptor instead of AVIVO.

Moreover, I would like to quote phoronix :

. Avivo under Linux allows accelerated video playback using the GPU's 3D engine rather than 2D. Any Linux software that uses the X-Video extension can utilize this 3D accelerated playback. This accelerated playback can be extended to non-X1000 graphics cards by enabling TexturedVideo.

So, isn't it possible to use the GPU to decode videos ?

Thanks

[bridgman]

There are two parts to video acceleration, typically called "decode" and "render". You can think of decode as being the first part of the playback pipeline and render being the second part, sort of like vertex and pixel processing in 3D.

Render acceleration (scaling, colour conversion, de-interlacing, post-processing) is usually the most CPU-intensive part of the pipeline and is therefore the first thing that gets accelerated. In the X world (Linux, Solaris, FreeBSD etc..) the Xv interface is the most common API for video render acceleration.

You can also use OpenGL to perform most of the processing by passing textures in YUV format and sending an OpenGL command to draw a rectangle (or two triangles) using that texture. OpenGL usually has a bit more CPU overhead and doesn't do any post-processing but sometimes there are other benefits.

On older ATI/AMD parts (up to R4xx) the overlay block included dedicated video processing hardware which performed most of the render acceleration, but starting with R5xx we removed the dedicated overlay hardware and now use the 3D engine to perform the same function. This is why TexturedVideo is now the preferred approach for 5xx GPUs and up -- the hardware used by VideoOverlay is simply not there any more.

Decode acceleration comes before render acceleration, so usually a video decode API (like XvMC) will build on a render API (like Xv). There are a number of projects underway to implement video decode acceleration on the GPU (I think Intel added some code for this to one of their drivers recently) but decode accel is nowhere near as common as render accel today.

[legume]

Thanks for your replies.

still plays slow HD videos.

My CPU is P4 3.2 Ghz. Isn't it possible to use the card capabilities to decode the video ?

Typical - I tested gl with a 1080 mpeg2 tests sream and as I said it's close to xv for CPU.

Unfortunately it looks like there is a problem with mplayer + ffmpeg h264 + gl output which makes the VO stage eat way too much CPU. I just tried with svn and it's still broken :-(

I don't think a P4 3.2 will quite do 1080 h264 (with a 2.1 GHz AMD I can only get 1/2 framerate on broadcast HD) it should be fine for 720.

AMD won't say yes or no to whether fglrx will ever get uvd support, there are other projects underway to do MC with GPUs.