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

[Luca Abeni]

Hi Martin,

Martin Storsj? wrote:
> Hi,
> 
> 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.


> 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.


> Lastly, the RTSP muxer uses this to coordinate the start NTP time for all 
> RTP sessions. Is adding a field to RTSPState for this ok? This needs to be 
> set once for the whole RTSP session, but is needed deep within the call 
> stack, in rtsp_rtp_mux_open, so passing it through as an argument isn't 
> awkward. Another option would be to store it in metadata for the RTSP 
> AVFormatContext.

No particular opinions on this. Looks ok to me, but it's better to see
what Ronald and Luca B. think about it.


				Thanks,
					Luca