[vlc] Re: Early picture / Late audio

[Peter Maersk-Moller]

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