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

Luca Abeni lucabe72
Mon Feb 18 09:18:42 CET 2008


Hi Michael,

Michael Niedermayer wrote:
[...]
>> 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.
> 
> Use time/1000*1000 and you loose less information.

If this is ok from the security point of view, I think this is the best
solution... I'll send a patch later


>>> 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? 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.
> 
> I dont think the absolute time values matter, but the relative ones likely
> do, for av sync, for clock drift (just think of what happens when playing a
> realtime stream and a clock which is a little faster than what the server
> uses)
Yes, you are right. Relative times are ok for A/V synch and for
compensating clock drifts (I ran some set of experiments during the
weekend, and they confirm that all the clients I could test are happy with
relative times).

Unfortunately, there are some problems with relative times when measuring
the RTT: in my setup, I use ffmpeg to send unicast RTP to an RTSP server
which forwards the RT(C)P packets to the clients, and reads RTCP RR packets
for recording some statistics. So, the RTT is computed in the RTSP server,
which does not know the base of the "NTP times" inserted by ffmpeg in
RTCP SR packets... As a result, it is impossible to reliably compute the
RTT :(

Summing up, an "av_gettime_more_secure() based" solution is ok in a large
number of cases, but not always...
I believe the AVFMT_FLAG_USE_TIME flag can solve the problem, but I do not
know if it is overkilling. What do you think about it?



			Thanks,
				Luca




More information about the ffmpeg-devel mailing list