[vlc] Re: Early picture / Late audio

[Peter Maersk-Moller]

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 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.

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).


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