[Live-devel] track synchronization with live555

[Ross Finlayson]

>  > It does, however, make this header information available for clients
>>  to use - see "MediaSession.hh".
>
>I know but the only place where this struct is filled in is within 
>RTSPClient class. And having a look at parseRTPInfoHeader(), I see 
>that only the first track is parsed in this header

Yes, that code currently works only when parsing the response to a 
*non-aggregate* PLAY command (i.e., a PLAY for a single track only).


>As the way I see it is quite different from the current 
>implementation, what I could suggest is to send a patch with a IFDEF 
>clause, allowing to switch between a SR-based synchronization 
>(current implementation), and a  rtp-info-based synchronization ?

No, I think you're confused here.  RTCP SR packets are *always* used 
to generate synchronized presentation times.  This is not - and never 
will be - optional functionality.  Note that "presentation time" is 
not the same as NPT ("normal play time").  For example, if the user 
seeks backwards in the stream, then NPT will move backwards, but RTP 
timestamps - and thus presentation times - from the server will 
continue moving forward (except for things like video B-frames, for 
which the presentation times may move a short distance backwards).

I was incorrect in my earlier response when I said that the RTP-Info 
header information could be used to generate presentation times prior 
to the arrival of the first RTCP SR.  That's incorrect because as you 
noted - the RTP-Info header information maps RTP timestamps to NPT, 
not presentation time.

Because NPT is an application-level concept, it's up to the 
application-level code that calls our library to keep track of NPT, 
and the offset between presentation time and NPT.  (This is what I 
presume the ongoing revision to VLC will be doing better.)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/