[FFmpeg-devel] Fix NTP time in RTCP SR packets

Luca Abeni lucabe72
Fri Feb 15 11:30:36 CET 2008

Hi Reimar,

Reimar D?ffinger wrote:
>> I suspect the problem you are pointing out is orthogonal
>> respect to my fix, since av_gettime() is already used...
> Yes, I still want to point it out.

Ok. I do not want to make ffmpeg less secure, so I really
want to address this problem.

>> Anyway, as far as I understand there is no choice, because the
>> standard mandates the use of NTP time. And I do not think that
>> this code is sending out any information about the local
>> computer (apart of the fact that the clock is currently set):
>> this code is used during live streaming, so the receiver can
>> already know that I am sending the packets now, even without
>> reading the NTP time in them :)
> Uh, as I understand it, this sends out the local time with usec
> precision. The server sure as hell does not know that, and it could e.g.
> be used to guess values if someone uses a stupid random number
> generator, system/network load and other things.
> IOW this is one of the things everyone planning a side-channel attack
> just dreams of.

I do not fully understand the problem here, but I believe you
because I am no expert in security.
I am just surprised, because you are basically saying that all
the RTSP server in the world have security problems (I checked
a lot of implementations, and they all properly fill the NTP

>> In any case, if we can find a standard-compliant way of setting
>> the RTCP fields without leaking information about the local
>> system, I am in favour of it (suggestions welcome).
> Why would it need to be standard compliant?

Because I want to use a libavformat-based server with different
clients, that expect a standard compliant server ;-)

> There is no single computer
> in the world that has a exact time, so requiring to send out the current
> time is impossible to fulfil anyway.
> Honestly, I am in favour of always sending out 0

This can work, but:
- Will make more difficult for some client to compensate for
   clock drifts
- Will make it impossible to measure some QoS statistics (for
   example, the RTT) in the server.

> Or just send out a number that increases by a fixed amount (or if the
> stream has timestamps, just send those back).

I think this will break almost all the clients, making it impossible
to synchronize audio and video (audio and video timestamps are
not comparable, and must be converted to NTP based on the NTP
time contained in RTCP SR packets. If this time does not increase
at the correct rate, A/V synch is impossible).


More information about the ffmpeg-devel mailing list