On Wed, Jul 07, 2004 at 10:35:01PM +0100, James Gatt wrote:The problem comes when switching between the user interface and mplayer - as far as I can tell, the user interface must give up the display so that mplayer can get exclusive access to it. This causes a glitch on the video output which upsets the television. I think the signal actually disappears briefly.
We have the same problem with Freevo. In our case pygame/SDL over directfb is the user interface for mplayer.
I think the solution for this problem might actually come from the (still unfinished) screen API. Much of the TV encoder stuff should actually be handled by the screen code. If turning the TV encoder on/off would be handled by the screen code the re-init might not have to happen.
I have a crazy idea that may be out to lunch, but here it is.
For Freevo I have been toying with pydfb and other directfb python bindings. I was thinking that when the UI application starts up it could initialise a number of windows and layers (I was thinking of using windowed mode). Each window could have a certain purpose and specific position from top to bottom. The bottom window could be used for the UI menus and display, top for and OSD text or graphics that you wish to display on top of everything else (including video), and the intermediate windows for video (pip, preview, and full display).
Ok, for the idea. The controlling application knows everything we need to know about the display and its layers and windows. I would love to be able to start mplayer with a switch like -wid (as for X11) but pass it a window, layer, or surface id that it would use to discover what it needs (geometry, colour depth, other properties) to display the video on said surface without redoing things like reiniting the TV encoder or mistakenly changing the resolution. I know this idea is more to do with mplayer but what do you think?
-Rob
