[FFmpeg-devel] [PATCH] add timeout to udp_read
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
> > > 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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel