[vlc-devel] Re: Problem playing some MPEG-4 audio RTSP/RTP streams
Laurent Aimar
fenrir at via.ecp.fr
Mon Feb 23 21:37:28 CET 2004
Hi,
On Mon, Feb 23, 2004, Ross Finlayson wrote:
> > 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=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
>
> 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.
Are you sure ? A few grep in my /usr/include give :
struct timeval
{
__time_t tv_sec; /* Seconds. */
__suseconds_t tv_usec; /* Microseconds. */
};
and then :
typedef __time_t time_t;
__STD_TYPE __TIME_T_TYPE __time_t;
#define __TIME_T_TYPE __SLONGWORD_TYPE
#define __SLONGWORD_TYPE long int
But I'm not sure, I may have mixed up some includes.
> 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.
Ok, thanks for this information, I've just commited a fix that make
rtsp://mpeg4.sunsite.utk.edu/wuot.sdp working.
--
fenrir
--
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>
More information about the vlc-devel
mailing list