[MPlayer-users] window destruction and pausing oddities
D Richard Felker III
dalias at aerifal.cx
Mon Sep 30 19:31:02 CEST 2002
On Mon, Sep 30, 2002 at 08:28:36AM -0700, Dave wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> On Mon, 30 Sep 2002, D Richard Felker III wrote:
> > [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> > On Sun, Sep 29, 2002 at 09:05:55PM -0700, Dave wrote:
> > > [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> > >
> > > Two questions:
> > >
> > > 1) Why is it necessary for the player window to be destroyed at the end of
> > > a file, even when the player is set to loop or is in GUI mode? In the
> > > former situation, this odd window behavior makes it impossible to play
> > > short clips while doing other things because the player window jumps
> > > around every time the loop goes around. In GUI mode, there is an annoying
> > > flicker as several windows seem to fight among themselves. IMHO, the
> > > proper way to have a clip terminate in GUI mode is to leave the last frame
> > > in the player window.
> > Yes this would be nice but it requires some significant changes to
> > libvo drivers.
> How significant? This seems like broken behavior.
Well it's not really broken. Consider for example that you could use a
different vo for each file:
mplayer foo.avi -vo x11 bar.avi -vo xv
In that case, it's necessary to uninit one vo and init a different one
for the next file. Keeping the window between one and the other
*could* be possible, if a separate X/window creation layer were added
that all the X-based vo's would use, but like I said it would be a lot
In the case of keeping the same vo between movies, it wouldn't be
quite as hard, but mplayer would need to be aware that the same vo is
being used, and avoid uninit and reinit in this case. Further, the
vo's would have to be fixed not to crash if their config function is
called more than once to change parameters. Most vo's are broken in
this respect, or at least they were last I checked.
> > > 2) I'm using SDL for output. I pause the clip, then move the player
> > > window somwhere else or switch to another virtual desktop. Why does the
> > > paused image stay in the same place on the screen hovering over everything
> > > else?
> > Broken XV drivers. Sounds like you're using nvidia.
> I've observed this effect with Xfree 3.2.x (or whatever it was that NetBSD
> 1.5.x used) and Xfree 4.x (which NetBSD 1.6 uses). The cards include an
> old Diamond Stealth 64 VRAM and an ATI Radeon 7000. I avoid nvidia cards.
Hmm, do you mean that the mplayer *window* (with decorations and all)
stays on top when you switch desktops, or just the movie image? The
Stealth64 doesn't even have overlays, so I assume you're using -vo x11
in that case. Please submit a full bugreport as this seems like it
could be a real bug in mplayer.
More information about the MPlayer-users