[FFmpeg-devel] [PATCH] add timeout to udp_read

Michael Niedermayer michaelni
Sun Dec 27 14:13:53 CET 2009


On Sun, Dec 27, 2009 at 01:45:21PM +0100, Reimar D?ffinger wrote:
> On Sun, Dec 27, 2009 at 01:23:48PM +0100, Michael Niedermayer wrote:
> > On Sun, Dec 27, 2009 at 01:15:55PM +0100, Reimar D?ffinger wrote:
> > > On Sun, Dec 27, 2009 at 01:09:51PM +0100, Michael Niedermayer wrote:
> > > > > I think it would also be a good idea to protect against the clock being
> > > > > reset by detecting av_gettime() < network_timeout_reference_time and
> > > > > adjusting network_timeout_reference_time.
> > > > 
> > > > why?
> > > > iam pretty sure ffmpeg will fail if the clock resets in 292
> > > > million years
> > > 
> > > I don't mean wrap-around, I mean if someone (e.g. NTP) happens to adjust
> > > the clock by e.g. a year, without an additional check our 10 ms timeout
> > > would just have become a 1-year and 10 ms timeout.
> > 
> > then we use the wrong clock
> 
> Well, I guess if there weren't the portability issues, av_gettime should
> probably use clock_gettime(CLOCK_MONOTONIC, ...) instead of
> gettimeofday.
> 
> > > It just seems reasonably simple enough to protect against this so I
> > > thought it can't hurt...
> > 
> > and if NTP slows the clock down like stoping it for a year ...
> 
> Which it won't. But apart from that it doesn't catch all issues, but it
> would catch a somewhat relevant one with only 2 lines of code or so.

what about using clock() for the timeout check?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091227/d8691fca/attachment.pgp>



More information about the ffmpeg-devel mailing list