[FFmpeg-devel] [PATCH] Sync the NTP timestamps for RTP streams

Martin Storsjö martin
Tue Mar 9 16:52:09 CET 2010


On Tue, 9 Mar 2010, Luca Barbato wrote:

> On 03/08/2010 11:52 AM, Luca Abeni wrote:
> > Martin Storsj? wrote:
> >> As discussed earlier, the NTP timestamps in RTCP sender reports are
> >> used to sync multiple RTP streams together. If first_rtcp_ntp_time in
> >> RTP muxers differ, though, the individual streams get out of sync.
> > [...]
> > 
> > [...]
> >> The attached patch series is an attempt at this. First the ntp_time
> >> function is made public, since the caller (be it the RTSP muxer or an
> >> external libavformat user) will need it to set coordinated NTP start
> >> timestamps. Is this ok, or should it be ff_ prefixed and left internal
> >> to libavformat for now?
> > 
> > I am not sure if we want a public av_ntp_time() function. I'd be
> > inclined to go for a private ff_ntp_time(), but I'd like to hear
> > other people's opinions too.
> 
> I think it could have some uses outside, yet it's quite simple so either
> way won't cause much harm.

Well, the one use outside would be for setting a sane value for the 
coordinated start time. But I'm ok with keeping it private for now, since 
it's simple to reimplement outside if needed anyway.

> >> Then the RTP muxer is made to check for a metadata with the key
> >> "ntp_start_time", and set the first_rtcp_ntp_time with the value in
> >> that key, if present. Is this acceptable, or should another field be
> >> added to AVFormatContext for this?
> > 
> > I like very much this kind of solution (and I think that adding
> > muxer-dependent fields to AVFormatContext is not a good idea). Maybe
> > we can use a prefix for the metadata to indicate that it is a parameter
> > for the RTP muxer (something like "RTP/ntp_start_time", or similar).
> > I expect we will need other metadata entries like this one (for allowing
> > setting the SSRC, the RTP timestamp offset, etc...).
> > If this is not considered an abuse of the metadata API (I like it, but
> > I'd like to hear Michael's opinion on this), patch 0002 is ok.
> 
> I think it's nice as well, if Michael finds that ugly we could just make
> a parameters api for this purpose leveraging the experience with the
> metadata api...




More information about the ffmpeg-devel mailing list