[MPlayer-dev-eng] sync problem when switching mpeg1 video streams via pipe

[David Toso]

Hi mplayer developers,

Again, I am trying to get mplayer to switch files mid-playback (as per previous thread
titled "Re: changing file mid-playback").

Rich suggested that I feed an MPEG1 stream through a fifo to mplayer, and switch 
the file it is read from mid-playback. I have implemented a "feeder" process which 
does exactly that and works as such:
    ./feeder | mplayer -demuxer 2 - 2>/dev/null 1>/dev/null
This opens a command console-like thing on stdin (of feeder), and supports the 
commands:

    load filename                                          start playing mpeg from filename
    loop filename [seconds]                          as with "load", but issue a "load filename" 
                                                                    every EOF or when reaching "seconds".
    stop                                                         stop playing. mplayer continues running 
                                                                    but window goes black and sound stops.
    quit                                                          closes the pipe, mplayer exits

The first "load" command issued brings up the mplayer window, and uses a silent 
mpeg containing a black frame. After this, the menu (connected to the feeder process 
via a pipe), takes control of playback. Every time the movie displayed by mplayer 
should change, "feeder" issues a "load" command. 

This is all working, and is quite nice. I will later have "feeder" pass slave-mode 
commands to mplayer via another pipe, for the purpose of adjusting contrast etc.

My problem is that after I have been playing an mpeg file for some number of seconds,
say 25, then issue a "load" to switch to another file, the audio of the first movie will
continue to play for about 2 seconds before changing, whereas the video changed
immediately. To be clear, during the 25 seconds of the 1st file, the video & audio
are perfectly synchronised. The overlapping audio is from time after the end of the
video that is displayed.

I am in the process of trying to figure out why this happens, and have some theories
but would like to bounce them off developers here, and perhaps someone here can
give me that golden answer I seek :-)

At first I thought that the buffers I use in "feeder" simply needed to be flushed, but
I quickly realised that at 8192 bytes, they have negligable impact on the stream 
synchronisation.

The files are MPEG1 so I then thought that maybe the audio frames & video frames 
for some given "time" in the file are not necessarily (or even particularly) close to
each other in the interleaved MPEG files. 

So does a GOP block actually contain the audio frames for that period? -- or can they 
be just about anywhere provided they are in the correct order?

If the former, then I should be simple to switch on GOP boundaries, and have a 
negligable impact on the playback. But given that GOP's are supposed to be around
12-15 frames, I can't see how this would result in the 2 seconds of audio stream 1 
I am seeing with video stream 2.

If the later is true, would I not then have to implement a full MPEG1 demuxer and 
synchronisation engine (bah --- steal it from mplayer :-) in order to switch cleanly
between the streams... AND, if it _is_ the case that the audio is coming that far
ahead of the video, is that something that mplayer needs for reasonable playback
performance, or Am-I-Just-Smoking-Too-Much-Crack (tm) ?

I've kind of been stuck on this part for a while and any help would be appreciated.

David Toso.

PS: Feature request: New codec "NNTP" reader with text-to-speech for audio and 
any images/text as the "video". 
PPS: And mencoder should be able to make coffee / fetch Mountain Dew.