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

Michael Niedermayer michaelni
Sun Dec 27 15:34:33 CET 2009


On Sun, Dec 27, 2009 at 02:51:03PM +0100, Reimar D?ffinger wrote:
> On Sun, Dec 27, 2009 at 02:13:53PM +0100, Michael Niedermayer wrote:
> > 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?
> 
> "On several other implementations, the value returned by clock() also
> includes the times of any children whose status has
> been  collected via wait(2) (or another wait?type call)."

well, if you insisnt on the hack add it but i still think we should use
a clock source that works (or undefined behavior if the user adjusts
time behind us hard)

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- 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/7656c002/attachment.pgp>



More information about the ffmpeg-devel mailing list