[FFmpeg-devel] Extracting NTP timestamp from RTCP
frothga at sandia.gov
Thu Nov 14 20:01:19 CET 2013
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
More information about the ffmpeg-devel