[vlc] Re: Early picture / Late audio

[Sigmund Augdal]

On Tue, Nov 23, 2004 at 09:15:34AM +0100, Peter Maersk-Moller wrote:
> Hi Ross
> 
> Thanks for the info.
> 
> Ross Finlayson wrote:
> >>I could be wrong, but I don't think the livedotcom demuxer
> >>throws away any data.
> >That's correct.  Also, the LIVE.COM library automatically uses the 
> >information in RTCP "Sender Report" (SR) packets from the server to set 
> >an accurate "pts" (presentation timestamp) value in the "StreamRead()" 
> >function (in "livedotcom.cpp").  The rest of the VLC code should be 
> >using these values (from audio and video) to do A/V sync.
> 
> After your oppinion, then what is the maximum acceptable time skew
> between corresponding audio and video packets ?
> 
> Does anyone know how VLC deal with skew ?
> 
> I here define the time skew as the intial time difference between the first
> video packet and the (time wise) corresponding audio packet.
> 
> Quite often skew larger than 1-2 seconds is impractical, but it
> depends on the application.

I think this constant is in the neighborhood of 300ms in vlc.

> 
> I once implemented RTSP based streaming for Vorbis for mp4live, but the 
> vorbis
> audio encoder was 5-6 seconds behind the video encoder for the first 
> packets so
> the skew was 5-6 seconds while a buffer time of 300 msec worked fine.
In vlc everything is strictly timestamped, a databuffer would be timestamped
before going into the encoder and timestamped when geting out of the
encoder, so that strict a/v sync could be kept. In such a case as this, vlc
would buffer video data up to a certain point, and then start dropping
oldest buffer untill sync was archived. (at least so I think, not sure on
all the details here). Same thing is happening for playback.

> 
> BTW, Ross. Does the live.com demuxer buffer data itself or is it the vlc 
> core ?
> If it is your demuxer that buffers, do you then ensure that you have at 
> least
> N msec of BOTH audio AND video before passing the data to upper layers ?  N 
> is
> here the buffer time (typical 1200msec).
The demux buffer up to one logical frame of data for each in-stream (if I'm
correct). Then data is buffered after being demuxed, but before being
decoded in the vlc core. This last buffer can be changed with --rtsp-caching.

Also note that we have had some issues with live streams lately due to
changes in the audio resampling code, but this should only affect audio, not
video.

Next note that (according to reports in the forum) live.com demux is
sensitive to faulty clock at your computer.


Sigmund


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

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