[vlc] Re: Early picture / Late audio

[Peter Maersk-Moller]

Hi Benjamin

Benjamin PRACHT wrote:
> On Mon, Nov 22, 2004, Peter Maersk-Moller wrote :
>>1) Is there a varibale that can be adjusted to increase the
>>maximum gap between audio and video packets acceptable ?
> You can try increasing the buffer size in the options of the livedotcom
> access_demux plugin.

I could be wrong, but I don't think the livedotcom demuxer
throws away any data. I think it is the (core) player, but I din't
read through the code - yet ;-)

Increasing the buffer time does not seem to help.

Obviously, if we buffer 1200 msec and we receive
a video frame that is more than N msec later where

   N = buffer time + internal buffer time + start_skew

then, the player has to throw away the frame. Let me
explain what I mean with time elements

   buffer time = The livedotcom buffer time (defualt 1200 msec)

   internal buffer time = This is the time af the samples forwarded
                          to the audio device but not yet played plus
                          other various things. This value could be 0.

   start_skew = This is the start skew between received video and received
                audio packets.

start_skew needs a little introduction. Assume the video encoder has an
ecoder delay of 3 frames (25fps = 120 msec) and assume the audio encoder
has an encoder delay of 2.12 secs. I know it is a little extreme, but
lets assume that is the case. Then ideally the player will from start
receive its first video frame 2 secs before it receive its first corresponding
audioframe. If this is the case, the N is

   N = 1200 + 0 + 2000 msec 0 3200 msec.

Internal (core player) buffer time is here set to 0. In this case,
the player should still play an audio frame which is received up to
3200 msec late since you CAN NOT assume that corresponding audio
and video frames are ideally interlevead (meaning following
rigth after each other).

Not everybody might agree with my interpretation, but at least
it is safe to assume that corresponding audio and video frames
WILL NEVER arrive at the player at the same time, so how
big a difference is acceptable. The buffertime (by default
1200msec for live.com) is not (should not be) the maximum
buffertime, but rather the minimum buffer time for both
audio and video.

 > Howevdr, it isn't sure it will solve all your
> issues. By design, VLC is quite sensitive to clock issues...

I could be wrong in my explanation, but which part is responsible
for handling start_skew as defined above ? Is it an issue
I should take up with Ross (live.com) ?

Of course the start_skew as defined has a practical maximu value,
but both Quicktime and (g)mp4player is quite tolerant on this.

>>2) If yes, is it possible to increase this value by default since
>>other players has a bigger value and getting end-users to adjust
>>this value manually is a support nightmare.
> It would be possible by recompiling the player, or distributing a
> tweaked proeference file (ok, both solutions are a pain...). I don't see
> any way to give VLC parametters using the RTSP channel (Thi could could
> perhpas be implemented in a totally incompatible way...)

Not sure I understand what you mean, but one could add parameters to
playlist like

   rtsp://server/file.sdp -buffertime 300ms

I did add that for (g)mp4layer and it works well, but as you point
out, probably quite non standard.

Anyway, Benjamin, if you want to test with live streams with various
skews, I can forward you the URLs, but I would need your IP-address(es)
to open up for your request.

--PMM

-- 
This is the vlc mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/support/lists.html