On Mon, 2006-08-14 at 20:17 +0200, Dirk Meyer wrote: > I came across a problem when writing kaa.player. When using xine it is > possible to keep the vo open between two files. This is a nice feature
It's also possible with mplayer too, using -fixed-vo. But only applies to certain vo drivers. kaa.player uses -fixed-vo with mplayer. > we should use. On the other hand, if the user does not want to play a > new file after playing is done and we keep the vo open, freevo won't With xine, closing the vo will involve deleting the stream. Or, alternatively, rewiring the stream (or video port of the last post plugin in the chain) to a null vo driver. Once the VODriver object is deleted it will release the display. The kaa vo driver in xine would preferably support being able to dynamically change the passthrough vo driver. Then you can replace it with a null driver when you want to unlock the display. It can't do this currently. > be visible because xv and fb based vo will write above freevo. So how This isn't a problem for xv. Freevo doesn't need xv except for playing video. The main app is drawn to another x11 window, which can be raised or lowered relative to the media player window (which uses xv). For fb this is a problem, yes. > can we make it possible? Should the user call die() when he doesn't > need the player? How can we notify the dead player to the user? The No, die() shouldn't be used for this. In fact I wonder if there's a need for die() to be ever used at all. > I hope this is clear :) I think I understand the problem. I think what we want is for the vo to be released when the stream is stopped (by stop()) or when the stream ends on its own and there are no further streams to be played (e.g. there is a callback connected to the "end" signal that plays a new file). Now, how to implement this. With mplayer, we use -idle, which keeps mplayer alive even when it isn't playing. However, with -fixed-vo, it will keep the vo alive. So I think we will have to remove -fixed-vo from mplayer's args. This should basically cause mplayer to work how we want: when it's not playing a video, it doesn't have a lock on the vo. For xine, it will require rewiring to null vo driver when stop() is called. For streams that end, we can just check the state after calling self.signals["end"].emit() and if it's still STATE_IDLE, then rewire to null vo. On a subsequent open() (or maybe play()?) we would reopen the original (non-null) vo driver and rewire the chain again. Ideally we wouldn't want to replace the kaa vo driver, but just the passthrough driver. The kaa vo driver can't do this yet, but I think in theory it's doable. I can add this feature to the driver control function. Jason. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Freevo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freevo-devel
