[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