[vlc] Re: Early picture / Late audio

[Derk-Jan Hartman]

The post from 15:50 today on this list is a perfect example of these 
effects :)

DJ

On 25 nov 2004, at 11:52, Sigmund Augdal wrote:

> 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
>
>
---
Universiteit Twente
Derk-Jan Hartman (d.hartman at student.utwente dot nl)
http://home.student.utwente.nl/d.hartman

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