compiz: artifacts when transforming videos

Please attach a photo or video of the screen that shows the corruption, and your /var/log/Xorg.0.log (so we have your configuration, etc.)

this is the log file. I will try to take a screenshot of my problems

I didn't manage to take a screenshot, but I used my cellphone to make a video. it's in 3gp format, I hope you can see it.
in order we can see:
1) minimize-maximize artifact
2) black (instead of transparent) shadow of a window over the video
3) fade artifact (when bringing the video on/off top)
4) move artifact
5) scale artifact (similar to move)
6) volume OSD not transparent if over the video

Unfortunately I can't seem to play that type of video, however the bug sounds familiar. Does the issue go away when compiz is turned off?

I can play it in ubuntu after having installer ubuntu-restricted-extras.
Yes, the issue goes away with compiz off

Okay thanks, yeah I can view it after installing that.

In fact, I've been able to reproduce the issue myself on an i945 system (my i965 system is currently experiencing bug 191027).

This is a video tearing (aka screen tearing) issue due to some problem with textured video running under compiz. I notice that if I run gstreamer-properties and switch from Xv to no-Xv, the issue goes away (and scaling still works properly). Since that seems to be a viable workaround, I'm dropping the priority a notch.

Possibly this is related to bug 201596. It might be worthwhile to experiment setting 'Option "TexturedVideo" "false"' (or "true").

It might also be worthwhile to test against version 2:2.2.1-1ubuntu4, before the new hw_overlay patch was applied; googling around a bit shows that some people saw a change in how Xv worked in Compiz at that point.

I confirm that no-xv is working, though it is a bit CPU intensive.
the setting "TexturedVideo" "false" is the default now.
putting it to true makes this bug disappear, but with a very high CPU usage (around 70%)
I'm now going to test the package 2:2.2.1-1ubuntu3

Ok 1ubuntu3 does not have this problem, but still uses lots of CPU (70%)

Okay thanks, that pinpoints what patch caused the problem, to the overlay patch. Unfortunately, that one is necessary to avoid some even worse bugs on some people's hardware, so we cannot easily drop it. Maybe in the future we'll have some better solutions, but meanwhile I hope the workarounds (no-xv, TexturedVideo, etc.) give you some alternative options.

The good news is that there is a *lot* of work going on upstream in this area, and I expect once Intrepid opens and we can pull in the newest X stuff in a couple months we'll have some new approaches to solving this. For now, I'll move this over to a wishlist since I think there isn't much we can do (other than forcing one of the workarounds - which as you noted are not that great either.)

Dear Bryce, I've discovered a *very* strange thing. If I launch the
video using the command
gst-launch playbin uri=file:///path/to/file
the video is WELL transformed and the CPU usage is low (using the
automatic gstreamer video output from gstreamer-properties)

don't you think this is strange too? since I thought that
totem-gstreamer should perform exactly the same as gst-launch

That is interesting; I wonder what gstreamer might be up to there.

Since I think this will be resolved once textured-video is solidly in place, I'm duping to our textured-video bug.