[vlc-devel] Re: Problem playing some MPEG-4 audio RTSP/RTP streams

[Ross Finlayson]

>  I have tested with rtsp://mpeg4.sunsite.utk.edu/wuot.sdp and it seems
>that live.com return a weird value (or I misunterstood the meaning):
[...]
>After a few seconds pts.tv_sec becomes (and stays) negative, and this 
>break the PTS
>computation and no audio samples are played.
>
>....
>pts.tv_sec=1077528378 pts.tv_usec=26051
>pts.tv_sec=1077528378 pts.tv_usec=26051
>pts.tv_sec=1077528378 pts.tv_usec=26051
>pts.tv_sec=1077528378 pts.tv_usec=26051
>pts.tv_sec=1077528378 pts.tv_usec=118930
>pts.tv_sec=1077528378 pts.tv_usec=118930
>pts.tv_sec=1077528378 pts.tv_usec=118930
>pts.tv_sec=1077528378 pts.tv_usec=118930
[*]
>pts.tv_sec=-530742096 pts.tv_usec=237329
>pts.tv_sec=-530742096 pts.tv_usec=237329
>pts.tv_sec=-530742096 pts.tv_usec=237329

Laurent,

Thanks for looking into this.

First, note that the "tv_sec" field of a "struct timeval" is unsigned, so 
you should really be treating this value as unsigned, not as a signed 
int.  The "tv_sec" value should actually be 3764225200, not -530742096.

But anyway, what's happening here is at the point [*] the first RTCP 
"Sender Report" (SR) packet is received.  These RTCP packets describe how 
RTP timestamps are subsequently mapped to 'real time'.  In this case, the 
'real time' given in the mapping is an unusual value (beginning with 
3764225200 seconds) that doesn't correspond at all to 'wall clock' 
time.  This is a bit unorthodox, but it's legal.

What's important is that prior to point [*], no mapping from RTP timestamp 
space to 'real time' had yet been received, so the LIVE.COM code had to 
estimate the presentation time value.  (It did this based on the 'wall 
clock' time when the first packet was received.)  That's why there's a 
discontinuity in the "pts" value at point [*].

The VLC code will (somehow) need to handle this discontinuity - e.g., by 
ignoring presentation time values prior to point [*].  Fortunately, the 
LIVE.COM code provides a boolean function
         RTPSource::hasBeenSynchronizedUsingRTCP()
that will tell you whether or not RTCP "Sender Report" packets have yet 
been received.  (This function will return False prior to point [*], and 
True afterwards.)  So, you can call 
"tk->rtpSource->hasBeenSynchronizedUsingRTCP() to check for this.

I hope this helps.


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>