[MPlayer-users] XVideo output fails unless Xine is also running
Ben Liblit
liblit at eecs.berkeley.edu
Tue Oct 15 09:39:02 CEST 2002
I've uncovered a few additional clues regarding this problem. First, to
quickly recap what we already knew:
- If another process is already using XVideo, then MPlayer gets XVideo
port 120 from adapter 1 ("NV05 Video Blitter") and works correctly.
- If no other process is already using XVideo, then MPlayer gets
XVideo port 119 from adapter 0 ("NV01 Video Overlay") and shows a
black window instead of video.
Now the new information:
- On a fresh display, before running Xine for the first time,
"xvinfo" reports that the XV_AUTOPAINT_COLORKEY boolean attribute is
set to
true (1) on adapter 0 ("NV01 Video Overlay").
- After running Xine at least once, "xvinfo" reports that the
XV_AUTOPAINT_COLORKEY boolean attribute is set to false (0) on
adapter 0 ("NV01 Video Overlay").
- When I first log in, MPlayer can run correctly, with no other
processes running, using port 119. However, after I have run Xine
at least once, MPlayer is no longer able to use port 119 correctly.
- If I run a tiny little program that just sets XV_AUTOPAINT_COLORKEY
back to true (1) on adapter 0 ("NV01 Video Overlay"), MPlayer is
once again able to use port 119 correctly. This lasts until the
next time I run Xine, which sets XV_AUTOPAINT_COLORKEY to false (0)
again.
- Adapter 1 ("NV05 Video Blitter") has no XV_AUTOPAINT_COLORKEY
attribute at all. When MPlayer fails to get port 119 and uses
port 120 instead, it is using this adapter 1. Thus, the value of
XV_AUTOPAINT_COLORKEY doesn't matter. This explains why MPlayer
*always* works when using port 120.
So I seem to have found a workaround without really understanding why it
works. The workaround is for MPlayer to set XV_AUTOPAINT_COLORKEY to
true if that attribute is supported by the XVideo adapter it has decided
to use.
Questions I'm left with:
- Just what *is* XV_AUTOPAINT_COLORKEY, anyway?
- How come Xine doesn't seem to need XV_AUTOPAINT_COLORKEY to be true
in order to work properly, while MPlayer does?
- Is the workaround I suggest above reasonable enough to make part of
the standard MPlayer XVideo output driver? If so, I'd be happy to
prepare / test / submit a patch.
Cheers!
More information about the MPlayer-users
mailing list