[vlc] Re: Early picture / Late audio

Sigmund Augdal sigmunau at stud.ntnu.no
Thu Nov 25 11:52:30 CET 2004


I'm not sure of the details, but when the time skew is too large vlc will
dropp data for one of the streams, this gives error messages like PTS out of
range, buffer too late, buffer too early etc.

Sigmund



On Thu, Nov 25, 2004 at 10:31:15AM +0100, Peter Maersk-Moller wrote:
> Hi Sigmund
> 
> Sigmund Augdal wrote:
> >>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.
> 
> Are you saying that VLC can accept an initial time skew of UP TO 300 msec
> where the time skew is defined as time difference between received
> corresponding audio and video packets (or frames) ?
> 
> If yes, what does it do if skew is 500msec or 1000msec ?
> 
> I may be missing something because in the next part you say that
> VLC buffers data when necessary (when skew > 0).
> 
> >>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.
> 
> But if buffersize (in time) is less than time skew between video and audio,
> then when VLC eventually received the awaited audio frame, the the 
> corresponding
> video frame would have been dropped.
> 
> What does VLC do in that case?
> What does it print as error message ?
> Is the buffersize adjustable ?
> And should that buffersize be large as default for robustness (except for
> small systems) ?
> 
> >>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.
> 
> I guess that (--rtsp-caching) is what controls how many msec you buffer 
> until
> you start play. Now my argument is that if you want to buffer N msec and you
> start receive the first video frame with timestamp V and the first audio 
> frame
> with time stamp A and the time skew between receiving the two packets was 
> S, then
> you need to buffer
> 
>     buffertime N+S+(A >= V ? A-V : 0)
> 
> though if (A < V), then other possibilities than buffer N+S exist. The 
> point is,
> that you can't determind how much to buffer before you have received the 
> first
> video packet (not necessarily frame) and the first audio packet (not 
> necessarily frame).
> If the first audio and video never comes, then you buffer forever. That 
> needs to be adresses
> too.
> 
> I suspect VLC just buffer for N msec and then starts play which isn't 
> exactly
> can be experienced as a robust method.
> 
> >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.
> 
> Have a link to what issues that may be ?
> 
> >Next note that (according to reports in the forum) live.com demux is
> >sensitive to faulty clock at your computer.
> 
> I'll check the forum. Thanks.
> 
> --PMM
> 
> -- 
> 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



More information about the vlc mailing list