[FFmpeg-devel] Fix NTP time in RTCP SR packets
Wed Feb 20 11:47:38 CET 2008
On Mon, Feb 18, 2008 at 09:51:25PM +0100, Michael Niedermayer wrote:
> On Mon, Feb 18, 2008 at 08:56:07PM +0100, Reimar D?ffinger wrote:
> > Nevertheless, the
> > specification does not really require this information,
> The part quoted said:
> "A sender that has no notion of wallclock or elapsed time may set the NTP
> timestamp to zero."
> ffmpeg as a POSIX program, has a notion of wallclock and elapsed time thus
> this statement does not really apply. It just says if you dont know X you
> may set it to 0. It does not say you may set X to 0 as you see fit.
FFmpeg yes, though if libavformat as a library is supposed to have such
a notion is a different question.
If the code was in libavcodec I would say it clearly may not use the
system time unless provided by the calling application.
> Thus if we set it to 0 we likely violate the spec, and as luca already
> said it does cause problems in practice as well.
If it causes problems that would mean though that there are cases that
are inside the spec and have problems. At least having a way to disable
it would make it possible to test and fix/improve clients for this
corner-case allowed by the spec.
And one final comment: A reliable clock is by far not a given thing,
e.g. FreeBSD running under VMWare has the clock running at roughly
double speed. And even if you take countermeasures like running an NTP
client time jitter of up to several seconds is possible. Would this
qualify as having "no notion of wallclock or elapsed time" to you?
More information about the ffmpeg-devel