[MPlayer-dev-eng] Re: Re: changing file mid-playback

[David Toso]

Hi Alban,

Alban Bedel <albeu at free.fr> wrote:
>>   - uses vo_sdl, frameless windows
>>
>>   - vo_sdl talks directly via socket to hacked wm2 (window manager) so
>>   that 
>>     initial placement of each mplayer window is pre-arranged. (stops
>>     drag artifacts associated with XMoveWindow).
>>   - in slave mode, the playback window does not accept mouse/key events.
>>   
>>   - mplayer starts "paused", so a pause (slave-mode) command must be 
>>     given to play the movie. (used for multi-mplayer syncronisation).
>>   - various means employed to give input focus to (menu) window _behind_
>>   the 
>>     mplayer windows, and the mouse has been totally disabled.
>Why not just use the -wid flags to have mplayer use a window you created
>yourself. That would spare you most of these ugly hacks. Or am i missing
>smthg ?

I am not using -wid for 2 reasons. 

The first is that I have _never_ been able to get -wid working :-( I've tried 
_many_ mplayer CVS dates, and many different types of window, all with 
no success. Does anyone have success here?

The second (and most important) is that the menu that the preview movies
are playing on top of, is just a single libSDL surface, and hence has no
(sub)windows that could be used to reparent the mplayer window. The
menu surface will change a lot, and coords of the mplayer windows may
also have to be scaled & offset on the fly.

For those reasons, I went down the painful path of hacking a window 
manager specifically for the PVR, and all the associated focus, and
mouse-blocking stuff.

If you can think of a better way of implementing the menu (still in SDL) so
that I can use reparented mplayer instances on the surface, I would find it
fantastic to know :-)

I have explored using a bunch of YUV overlays attached to the surface, and
having six other threads periodically update the overlays with frame data 
coming from six mplayer instances, then the main thread 'updateRects' the 
surface (+ overlays) X times per second (while also looking for keyboard 
events). I tried having vo_sdl place the YUV data in shared memory.
It _did_ look like it would work, but I couldn't seem to get CPU usage for the 
SDL menu process down from about 30% :-(. So this method quickly became 
a non-candidate.

>> I am trying to figure out if it would be possible to start playing one
>> MPEG file, then at some point later during it's playback, switch to
>> another MPEG file, without of course completely restarting mplayer. I
>> don't know what the file will be in advance (but will play the rotating
>> symlinks game if that is an option :-).
>>  
>> To do this I was thinking about hacking vo_sdl (sorry author) again so
>> that it does not uninit & init. I was guessing I then need to hack
>> something in the demuxer. (and add input options for all this).
>
>Just use -fixed-vo if you don't want to uninit/init the vo for each
>file. If sdl doesn't support it just fix it that would be better for everybody.
>But I see no reasons to go hacking the demuxers.

Yeah, Tobias mentioned -fixed-vo... I am looking into that. 

>> Can you provide any advice as to where I should start (and NOT start :-)
>> in the demuxer to achieve this? Or if that sounds like a dumb idea, is
>> there a better way to do it?
>
>Try the command 'loadfile "filename"' There is also loadlist to load playlists.

'loadfile' eh? Is that in the OSD menu or in -slave mode protocol? I will port it 
to -slave mode if necessary, it sounds like exactly what I need.

>> Also, assuming that this would work, can I avoid uninit & reinit of any
>> other subsystems? (I can guarantee that movies will all be of the same
>> encoding and codec -- most likely MPEG1).
>
>You can try but it's no good idea and not very useful imho.

Cool :-), I am just trying to be a little facist about spikes in CPU/IO usage, so
that the PVR software as a whole performs adequately (and smoothly).

Thanks Albeu, i will look into 'loadfile' straight away.

David Toso.