[FFmpeg-devel] Extracting NTP timestamp from RTCP

[Fred Rothganger]

On 11/09/2013 11:06 AM, Reimar Döffinger wrote:
> Well, according to that the documentation says that the first frames 
> were recorded on January 1, 1970. That obviously is not true, and from 
> the code it quite obvious that you don't use 0 to mean January 1,1970 
> but it means unknown/not yet found/... That should be documented (and 
> there is of course a question if it's a good idea. INT64_MAX might be 
> a better choice.

There are a few things worth noting here:

* It makes sense to define a special value that means "not set", and 0 
is the simplest choice. INT64_MAX also makes sense, though UINT64_MAX 
would make more sense. IE: many of these closely related fields, 
including start_time_realtime, are currently defined as signed values 
(int64_t rather than uint64_t). RTCP NTP time is specified as unsigned, 
so this may be a latent bug in FFmpeg.

* The patch I sent tries to make the minimal amount of change necessary 
to implement the feature. It does not assume that 0 means unset, only 
that nonzero means set. IE: If the true start time was 1970/1/1 at 
midnight, the patch would still work. It would merely do some trivial 
extra work recalculating the field each time an RTCP packet comes in (on 
the order of once per second).

* I imagine a use-case where it would be useful to set 
start_time_realtime to an arbitrary value. RFC3550 allows the clients 
and servers in a session to agree on an arbitrary time-source different 
than current real-world NTP.
     Consider the following (fictional): I run an online archive of old 
35mm home movies. I digitize them and each one is timestamped with its 
best-known start time. I allow users to query by time, and then initiate 
steams of the movies. I would like the server to send values for the 
real time the movies were originally recorded, rather than the current 
clock of the server. It is conceivable that one of those 35mm films was 
made during a new year's party in 1970.
     Currently the server code in FFmpeg can't support this use-case. If 
the user passes in a value in AVFormatContext.start_time_realtime, it is 
either ignored (overwritten) or assumed to be relative to the epoch of 
the server's clock.
     The client code does not reference the clock, so it can handle any 
case.