[MPlayer-dev-eng] Sync problems switching mpeg1 streams

[D Richard Felker III]

My best recommendation would be to implement (at least basic) mpeg ps
parsing in feeder and switch over at a valid point rather than
wherever the file position happens to be. I'm having to do something
similar with ogg audio for a radio server I'm working on because the
ogg format is so brain damaged.

Rich


On Sun, Jan 12, 2003 at 03:07:09AM +1000, David Toso wrote:
> Hi mplayer developers,
> 
> Arpi <arpi at thot.banki.hu> wrote:
> > no wonder - have you ever heard/think of audio buffering? :)
> > and it's not even in mplayer, it's done by the soundcard (hw or driver).
> 
> Ok I think I now have some idea of what is happening, but have no idea of how 
> to fix it. (It does not appear to be audio buffering in HW/driver).
> 
> A little background for those who have not followed the previous related thread: 
> 
>      ./feeder | mplayer -delay 0.216 -demuxer 2 -
> 
>   The feeder program presents a prompt, to which I enter:
> 
>       load 1.mpg
> 
>   The feeder program opens 1.mpg, reads from it and sends the data to mplayer,
>   which starts playing, which also causes mplayer to initialise its vo module, and 
>   displays 1.mpg playing in its window.
> 
>   At some point (say 30 seconds) later I type at the feeder prompt:
> 
>       load 2.mpg
> 
>   Internally, feeder closes 1.mpg, opens 2.mpg and starts sending that to mplayer 
>   instead. Since these are mpeg files, mplayer hapilly treats the 2nd file as a 
>   (slightly broken) part of the original stream, and just skips ahead to valid frames. 
>   There is no noticable artifact on the switch between streams.
>  
> The "-delay -0.216" is to compensate for PAL 3:2 pulldown, as these mpeg files 
> are actually rips from PAL (region 4) DVD's. This does not have any effect on the 
> problem I am having (other than to correct lip-sync).
> 
> The problem is that when I switch from stream 1 to stream 2, mplayer takes a 
> _long_ time, say 10-15 seconds, to regain synchronisation between the video 
> and audio.
> 
> I have verified this by looking at the A-V field from the running statistics output 
> of mplayer. I would normally see rapid fluctuation between say "A-V:  0.022" and 
> "A-V: -0.045", when the audio and video _are_ in sync. 
> 
> Upon switching to the second stream (30 seconds later) that field goes up to 
> some abnormally high figure like "A-V:  0.725" and gradually (over 10-15 
> seconds) settles back down to the normal range, after which the video &
> audio do look to be in sync again.
> 
> I wonder if there is any way to ensure that there will be no large loss of sync
> when switching mpeg streams? 
> 
> I have tried -cache but, of course, that just results in the effect of the feeder 
> commands being delayed by some time proportional to the cache size.
> 
> Any help would be much apreciated.
> 
> David Toso.
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng