[FFmpeg-devel] [PATCH] Calculate RTCP SR timestamps from packet timestamps

Martin Storsjö martin
Sun Mar 28 13:28:56 CEST 2010


On Sun, 28 Mar 2010, Luca Abeni wrote:

> On Sun, 2010-03-28 at 13:12 +0300, Martin Storsj? wrote:
> > Currently, the timestamps for RTCP sender reports are calculated based on 
> > the system realtime clock. Since the start time for the RTP muxer can be 
> > set through the start_time_realtime field, this may be slightly (or quite 
> > much if the user explicitly wants that) different from the actual current 
> > time. This leads to sending RTCP SR packets where the RTP timestamp is way 
> > off from the RTP packets at the same time.
> 
> In my understanding of the RFC, the only important thing is that the RTP
> timestamp contained in the RTCP SR packet "matches" the NTP time
> contained in the same RTCP packet. Isn't this correct?

Yes, that's my understanding too. But nevertheless, it feels weird to send 
an RTCP packet syncing the NTP time to RTP timestamps for a RTP timestamp 
very far off from the current RTP packets.

> I fear your patch can create problems when the application does not send
> the frames "regularly", but buffers some of them to perform bandwidth
> smoothing.

Even in this case, the packets should be sent almost regularly, since it 
still is realtime transport protocol...

> Have you seen some problems with the current behaviour? Can you describe
> them? (maybe some client is making assumptions about some relationship
> between RTP timestamps and RTCP timestamps?)

No, I haven't seen any concrete problems, but I felt it would be more 
consistent this way.

The intent and idea is to contain all realtime clock usage to initializing 
first_rtcp_ntp_time - that way, the user can set that (via 
start_time_realtime) to whatever start time he wants, and every NTP 
timestamp in the session is sent relative to that. As Reimar pointed out, 
the absolute values of the timestamps don't really matter, and in this 
way, a user could choose to send packets with a time base other than the 
current realtime.

// Martin



More information about the ffmpeg-devel mailing list