Use Compiz' "video" plugin when available

its a quite big patch, and I'm not confident in having it included into ubuntu without references who did the patch, and what's upstream's opinion on this.

As can be seen from http://lists.freedesktop.org/archives/compiz/2007-March/001576.html, the patch was done by David Reveman. I have no idea what the mplayer developers think of the patch.

After doing a bit more digging, it seems this patch needs quite a lot of rewriting to be really acceptable upstream. Even the patch author (David Reveman) doesn't think it's really appropriate for upstream.

I'm not particularly interested in doing that rewriting. I might try to do a gstreamer compiz output plugin since that would be much more useful for me, if someone else doesn't beat me to it.

When the path is suitable for upstream, please reopen this. I'm closing it as Won't Fix for now.

David Raveman has just released a new version of this patch... I hope it will be included.

http://lists.freedesktop.org/archives/compiz/2007-July/002494.html

Please give us pointer to comments/discussion from the mplayer developers on this patch.

Is there a reason for patching the xv driver to support both compiz video and xv instead of creating a separate compiz video output driver for mplayer, which would then fall back to xv if compiz video isn’t available? All other output methods have separate plugins (e.g. xv, x11, opengl, sdl, framebuffer).

Seems to me that hacking the compiz video functionality to the xv driver makes both harder to maintain and enhance. For instance, the xv driver only allows the OSD and subtitle overlays to be drawn to the original video frames before they’re scaled to the target size. On the other hand, the compiz video driver would be able to use composited overlays for OSD and subtitles. They wouldn’t be dependent on the video resolution and aspect ratio.

The opengl driver does that using separate textures. Not only does it look really nice, it allows the subtitles to be below the video image if the video doesn’t fill the entire screen vertically.

On Mon, 2007-07-23 at 17:22 +0000, Johan Kiviniemi wrote:
> Is there a reason for patching the xv driver to support both compiz
> video and xv instead of creating a separate compiz video output driver
> for mplayer, which would then fall back to xv if compiz video isn’t
> available? All other output methods have separate plugins (e.g. xv, x11,
> opengl, sdl, framebuffer).
>
> Seems to me that hacking the compiz video functionality to the xv driver
> makes both harder to maintain and enhance. For instance, the xv driver
> only allows the OSD and subtitle overlays to be drawn to the original
> video frames before they’re scaled to the target size. On the other
> hand, the compiz video driver would be able to use composited overlays
> for OSD and subtitles. They wouldn’t be dependent on the video
> resolution and aspect ratio.

This is indeed the suggested course, although having it in the xv driver
does allow it to seamlessly fall back on Xv if the compiz plugin goes
away while the video is playing. The original patch is somewhat of a
proof-of-concept, really, although it does work.

I know where the main changes are located in this, look at the file,

libvo/vo_xv.c

this is where most of the changes are.

This would seem to be a reasonably important problem to be working on if compiz is indeed to be standard. It's a shame to see the bug closed for so long. There are not even patched mplayer versions of rc2 available for ubuntu users to download it seems.

Hi Chris! Sorry for bumping this up, but I have a small problem installing it from a branch. It seems not working with a compiz's video plugin, thus no video is seen. Just tried to apply a patch manually from the link above, and it works. Can you check please a code in the branch?

This is very desirable.

I have modified David's patch to make a new compiz vo driver and have built a working mplayer package using it - is there any use in continuing this bug or is upstream completely opposed or something?

On 9/7/08, Sam Brightman <email address hidden> wrote:
> I have modified David's patch to make a new compiz vo driver and have
> built a working mplayer package using it - is there any use in
> continuing this bug or is upstream completely opposed or something?
>
Upstream isn't implacably opposed to the concept (or, at least, wasn't
last time I checked), but doesn't seem likely to accept the patch as
it is. In particular, they objected to the hijacking of the Xv video
output - making it a separate video output driver would make the patch
much more likely to be accepted.

At least in-principle acceptance upstream would be a prerequisite of
patching the Ubuntu package.

That said, I'm not sure the video plugin is actually terribly useful
now - the big Xv-with-Compiz bugs have mostly been fixed in the
drivers. It was supposed to be faster than Xv, but I've seen no
benchmarks, and Xv is plenty fast enough for me already ;).

Using the most up-to-date Hardy and EnvyNG to get Catalyst 8.6 still produces buggy video playback for me. Looking at what David wrote in the mailing list, I'm not sure that this is necessarily meant to be faster than Xv: he refers to resource usage, not speed. Here is my adapted patch to put this in a new -vo compiz driver.

The "new compiz" driver is mostly working excellently for me. However, I have encountered one problem - sometimes I get nothing but a black screen full screen (I always just quit and turn off desktop effects when it happens so haven't tried windowed). Seems a bit random but nothing crashes and mplayer seems to be playing the video just fine - you get sound and responsiveness. Some kind of race condition on an x resource? Any ideas from someone who knows this area?

I have just noticed this bug marked won't fix and wishlist. Is a bug affecting core functionality not a bit more than wishlist? The point here isn't to be able to play multimedia in some new and groovy way, it's to be able to play it at all in a usable fashion. As for won't fix, people here have not been overly negative about this and my revised patch would seem to overcome the main objection from upstream. I repeat that this is still an issue (and in fact in more than just mplayer). What is the problem?

Sam Brightman <email address hidden> writes:

> I have just noticed this bug marked won't fix and wishlist. Is a bug
> affecting core functionality not a bit more than wishlist?

if you intend to work on it, feel free to assign the bug to yourself and
attach diffs with proposed fixes. the status is used to help developers
to mark their priorities and workload.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Please see my comment https://bugs.edge.launchpad.net/ubuntu/+source/mplayer/+bug/121476/comments/15 with attached diff.

What does upstream think of this new patch? Have you discussed it with them?
"""
At least in-principle acceptance upstream would be a prerequisite of
patching the Ubuntu package.
"""
If you can get their (favourable) opinion and link to the discussion, that will make it much easier to justify applying the (pretty big) patch.

All I have done is move the patched xv video out driver plus David Reveman's patch into a new compiz driver, so this explains the bulk of the patch: just the existing xv code moved into a new file. I have only read the discussion surrounding David's submissions (I think freedesktop list) which seemed to include someone from Ubuntu as well (there are some links above in this bug). The first suggestion there was to move this to a separate driver, which I have done - there was some later suggestion to remove code duplication but the driver sharing was the main objection from upstream as far as I could tell. I have had no contact with upstream, and it seemed like only David or perhaps someone else from Compiz had.

Reinhard Tartler wrote:

> the status is used to help developers to mark their priorities and workload.

Launchpad provides functionality for users as well as developers. Downplaying user feedback and frustrations causes antagonism towards developers which I can only assume they don't want. Especially when such status contradicts Launchpad's own guidelines - https://wiki.ubuntu.com/Bugs/Importance

yes, ask the mplayer developers to review or accept the patch. that way more users will benefit from your code, you will get constructive (read: useful) feedback, and it will find its way into ubuntu automatically.