[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