[MPlayer-dev-eng] Re: A/V sync problem with independent demuxers

[Arpi]

Hi,

> >it's all demuxer problem, it doens't (shoudl not) happen when playback
> >normal files or use demuxers written by me.
> 
> Again, I think you misinderstand.  My demuxers (audio and video) are merely 
> delivering buffers to the rest of MPlayer in FIFO order, and they *are* 
> setting "pts" correctly.  (I have confirmed this.  Note that the "pts" for 
> a RTP stream comes from the RTP packet timestamp (calibrated by RTCP), and 
> is completely independent of the time at which the packet arrived, or the 
> time at which the demuxer read the packet.  So, I'm quite sure that they're 
> accurate, and in fact the "A-V:" display at the bottom of the screen 
> matches the actual asynchrony that I'm hearing/seeing.)

Nice. Then teh only reason i can imagine is that your demuxer blocks reading
of packets, ie:
mplayer tries to read an audio chunk - get it, send to audio card
mplayer tries to read a video frame - get it after some delay (blocking in
demuxer) then display it. but whiel waiting for this video chunk the audio
buffers get empty.

I mean the demuxer should never delay block, ie demux_fill_buffer()
shouldn't take longer than few ms. For demuxers using the stream layer (most
ones, except your and tv and xmms) may use teh cache2 to buffer up enough
data in background to avoid blocking caused by i/o.
Probably you should add some kind of buffer/cache to your demuxer?

> How is the "a_buffer_delay" value computed? 

RTFM DOCS/tech/general.txt
and RTFS mplayer.c A-V sync block

> Can it change over time, and 
yes

> is there any way in which this computation could be getting messed up?

no, unless your sound drivers or audio codec is *broken*

> >the a-v core doesn't care if your steram sare independent or interleaved
> 
> That may be true, but the effects I'm seeing are very real, so I have to 
> wonder why MPlayer is (sometimes) having A/V sync problems with incoming 
> MPEG/RTP streams, and not when the file is being played directly.  I know 

see above

> that (i) each demuxer is delivering packets to the rest of MPlayer in FIFO 
> order, and (ii) these packets are each being given a correct "pts" value, 
> which is why I'm wondering if the problem might be related to the fact that 
> - in my case - the audio and video demuxers are independent.
> 
> Next, I'll try playing around with "-autosync" and "-mc" to see if I they 

they won't help
-autosync is for workaroudn sound driver bugs, -mc is to lower a-v correction


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
    "However, many people beg for its inclusion in Debian. Why?" - Gabucino
  "Because having new software in Debian is good." - Josselin Mouette
"Because having good software in Debian is new." - Gabucino