no video output module play nice with Compiz

Bug #162664 reported by Bogdan Butnaru
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mplayer (Ubuntu)
Invalid
Undecided
Unassigned
totem (Ubuntu)
Invalid
Undecided
Unassigned
vlc (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

This concerns Ubuntu Gutsy (and earlier versions). It was written for VLC, but you can substitute [mplayer|totem|other video players] for VLC anywhere in the following and it's still valid.

It's a shame that even with Compiz working very well now, there is no suitable VLC output plugin that allows all the nice visual features to work correctly.

I've tried everything I have installed by default:

* X11 is the only one where Compiz effects work: Shadows are displayed correctly over running video, transparency works both for the VLC window and for windows above the video, and the window is correctly transformed by effects (eg, the cover-view task switcher).
However, the video scaling is atrocious: it seems that only basic resizing is used, which looks horribly pixelated. Worse, subtitles are rendered in the video resolution, so even those are pixelated when the video is scaled (eg, full-screen).

* XVideo looks great (eg, nicely-scaled, and even subtitles look good). However, all effects are broken: since only the "overlay patch" is seen by Compiz, shadows are drawn as black or green blobs, window transforms don't work (although when the transformed patch happens to appear over the "normal" area with the normal colors we get a patch of untransformed video), and any transparency disables the video.

* The GL output is even worse than XVideo: it's simply drawn over everything, including VLC's menus (which are virtually unusable).

* Funnily enough, the ASCII-art module actually works great—all transformations work correctly. But... it's ASCII.

Something should be done to allow better interaction between VLC and Compiz's effects. I suppose an upgrade to the X11 mode would work (if I understand correctly it just paints the video on a normal window), perhaps using OpenGL in a background buffer to do pretty scaling, and drawing the OSD (including subtitles) above it, _after_ scaling. This is probably not lightning-fast, but that would only be a problem with HD video, which I don't expect to work through Compiz anyway except on very high-end machines. We might add some kind of automatic fall-back to whatever is the most efficient display mode in huge-video cases.

Revision history for this message
Bogdan Butnaru (bogdanb) wrote :

This bug actually applies to all of Ubuntu's video players, I'll edit it and attach it to the others I'm using (MPlayer and Totem).

description: updated
Revision history for this message
Bogdan Butnaru (bogdanb) wrote :

By the way, there is a patch that (almost) fixes this for MPlayer, there's some info at http://smspillaz.wordpress.com/2007/10/18/unlocking-the-full-video-potential-of-your-video-card/

It's not perfect (maximizing breaks the aspect ratio, and if you make the window transparent you can see the (useless) blue rectangle of XV through it), but it's a start. It should probably be included in Ubuntu's mplayer.

There are also a few hints on how to bypass Xv on other players at http://thedarkmaster.wordpress.com/2007/08/10/solving-video-playback-problems-in-compiz-fusion-beryl/

But this doesn't work great in VLC, because of scaling issues (as described above).

Revision history for this message
Sebastien Bacher (seb128) wrote :

that looks like a video driver or compiz issue rather

Revision history for this message
Bogdan Butnaru (bogdanb) wrote :

Yes and no.

On the one hand, the video drivers (intel, nvidia, ati) all behave the same way in the situation described above. They actually do what the software tells them to do, so they're not technically buggy. And technically so does Compiz:

The Xvideo method by definition works using an overlay color, with the video superimposed in hardware just before being sent to the screen. That's AFAIK beyond Compiz' ability to affect behavior, and other than disabling all effects on windows that are using it it's impossible to avoid the nasty artifacts.

The X11 method should (and does) work, since the video frames are rendered in a normal X window that Compiz can correctly transform. However, none of the applications I've tried (MPlayer, VLC, Totem and Xine) have nice scaling when that's used. I think this is because it's a relatively slow display method, and applications didn't bother to use a smart software scaler for that case. (There might be some technical limitations I'm not aware of, though.) I think this could be solved by including a good scaler in _each_ applications output plugin, but see below.

The OpenGL method should work, but I have yet to see an OpenGL app working correctly in a window under Compiz (on my machine, I've seen it in demos though). This is probably the only case where Compiz is broken, but I don't think there's a quick fix for that. Also, I think it'd be slightly inefficient even if it worked.

In conclusion, as far as I can tell, Xvideo can't work under Compiz by definition, simple X11 output would work but would be slow and needs all applications to fix their output plugins, and OpenGL is hard to fix.

On the other hand, Compiz does have a video output plugin which is very nice: it's really efficient speed- and memory-wise, does nice scaling and (on some cards) YUV-conversion in hardware, and also has some nice quality implications that are technically impossible for the other modes. According to the first link I posted, this is supposedly relatively easy to implement by modifying an existing plugin. So, seeing that all applications need to update their video output plugins to work correctly in Compiz (see above), they might as well modify them to use Compiz. (The patch for MPlayer that was linked above even features instant switching between Compiz and Xvideo while running.)

I know this should be reported upstream, too (and I think it is, actually), but it can't hurt to track it here, too. Also, there might be an Ubuntu developer or two who want to work on this, at least for Totem.

Revision history for this message
Alex Bennée (ajbennee) wrote :

I'm not sure if this is related or not. On my setup:

15:19 alexjb@alexjb-desktop/x86_64 [Desktop] >cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"

15:21 alexjb@alexjb-desktop/x86_64 [Desktop] >dpkg -l mplayer
ii mplayer 2:1.0~rc1-0ubuntu13.1 The Ultimate Movie Player For Linux
ii xorg-driver-fglrx 8.452.1-1 Video driver for the ATI graphics accelerato (envy installed)

I get flickery video playback with gstreamer, totem and mplayer. It looks very much like the video redraw is out of sync with the screen refresh. I experimented with the -vo option of mplayer and got the following results:

xv, gl, gl2, sdl - flickers horribly
x11, ggi - works, nice stable display
dga - crashes X
xvidx, xover - no driver loaded

So I don't think it's a problem with the low level driver, just some of the display modes don't sync while others do.

I currently have set my ~/.mplayer/config to:

15:24 alexjb@alexjb-desktop/x86_64 [Desktop] >cat ~/.mplayer/config
# Write your default config options here!
vo=ggi

As a work around. I've also uninstalled totem-mozpluging to use the mplayerplugin

Revision history for this message
Kjell Braden (afflux) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Hardy Heron. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

Changed in vlc:
status: New → Incomplete
Changed in totem:
status: New → Incomplete
Changed in mplayer:
status: New → Incomplete
Revision history for this message
Bogdan Butnaru (bogdanb) wrote :

This is still happening with the latest up-to-date hardy.

Changed in vlc:
status: Incomplete → New
Changed in totem:
status: Incomplete → New
Changed in mplayer:
status: Incomplete → New
Revision history for this message
Matthias Andersson (matthias-andersson) wrote :

I'm also experiencing this in Intrepid Ibex. Only setting Visual effects (system-preferences-appearance) to none gives a stable playback.

My graphics card is an ATI Radeon 9800XT.

Revision history for this message
Bogdan Butnaru (bogdanb) wrote :

I just realized I didn't have this problem anymore on Intrepid. I'm using VLC with the XVideo extension, and everything seems to just work: video quality is good, and the window is properly transformed (including transparency and task switching).

I'm not sure if it's the Compiz guys or the Intel driver people (I've got one of those GMA9** things), but somebody did a great job :)

Matthias, did you check if the video extension is enabled in Compiz?

Revision history for this message
Bogdan Butnaru (bogdanb) wrote :

Setting this as invalid on every video player, since they all work perfectly on my setup using Xv.

If someone can't use it it's almost certainly either a Compiz misconfiguration or a driver problem.

Changed in mplayer:
status: New → Invalid
Changed in totem:
status: New → Invalid
Changed in vlc:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.