Re: vlc und mplayer - race conditions?

From: Bernd Walter <ticso(at)cicely7.cicely.de>
Date: Wed, 25 Aug 2010 13:34:29 +0200

On Wed, Aug 25, 2010 at 01:07:02PM +0200, Harold Gutch wrote:
> On Wed, Aug 25, 2010 at 11:43:05AM +0200, Heino Tiedemann wrote:
> > Nicolas Rachinsky <fbsd-de-0(at)ml.turing-complete.org> wrote:
> > > Du kannst ja mal schauen, ob zurücksetzen mit xvattr (x11/xvattr) das
> > > Problem behebt.
> >
> > Cool - das klappt!
> >
> > #> xvattr -a XV_AUTOPAINT_COLORKEY -v 1
> > Found Xv 2.2
> > XV_AUTOPAINT_COLORKEY set to 1
> >
> >
> >
> > Fragt isch nur, was mir das im täglichen Umgang hilft.
> >
> > Ich kann nicht nicht jedesmall dieses Komando aufrufen, nur weil ich
> > mal nen anderen Player als mplayer benutzen will.
>
> Wenn du indem $PATH z.B. $HOME/bin vor allen anderen Verzeichnissen
> hast, könntest du es quick and dirty so lösen dass du ein Shellscript
> ~/bin/mplayer anlegst, das mplayer aufruft und dem einfach alle
> Parameter weitergibt, und als zweites dann xvattr wie oben aufruft.
>
>
> > Letzendlich muss das im mplayer gefixt werden, das der den Zustand
> > sauber hinterlässt.
>
> Richtig, das wäre die non-"quick and dirty" Lösung. Je nachdem wieviel
> Zeit ich hätte und wie sehr es mich stören würde, würde ich es im
> mplayer fixen oder wie oben.

Das geht eben nicht zuverlässig, weil so ein Prozess auch mal crashen
kann.
Wie ich inzwischen weiß hat mplayer das in seiner Initialisierung
übrigens 2002 gefixed - ich denke das wäre lange genug gewesen, damit
auch andere Programme das getan hätten, anstelle sich auf sowas
zu verlassen.
Das Attribut ist übrigens dafür zuständig zu definieren in welcher Art
die überlagerung mit dem XV-Bild geschieht.
Ich finde das sehr eigenartig, dass ein Programm was eine Überlagerung
benutzt diese unvollständig definiert.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 25 Aug 2010 - 13:34:44 CEST

search this site