[FFmpeg-devel] [PATCH] add timeout to udp_read
Michael Niedermayer
michaelni
Mon Nov 16 04:03:20 CET 2009
On Sun, Nov 15, 2009 at 11:41:08PM +0100, Hagen Schmidt wrote:
> On 07.10.2009 at 14:05, Michael Niedermayer wrote:
> > On Wed, Sep 23, 2009 at 10:30:26PM +0200, Hagen Schmidt wrote:
> > > On 15.09.2009 at 03:03, Michael Niedermayer wrote:
> [...]
> > > static int decode_interrupt_cb(void)
> > > {
> > > - return (global_video_state &&
> > > global_video_state->abort_request); + if (timeout_network &&
> > > !timeout_expired && reference_time) { + timeout_expired =
> > > av_gettime() - reference_time > timeout_network * 1000; +
> > > if (timeout_expired)
> > > + fprintf(stderr, "Timeout for receiving network
> > > stream expired after %i msec\n", timeout_network); + }
> > > + return (global_video_state &&
> > > global_video_state->abort_request) || timeout_expired; }
> >
> > is it neccesary to design this so complex?
> > dosnt
> > if (reference_time && av_gettime() - reference_time >
> > timeout_network){ fprintf(stderr, "Timeout for receiving network
> > stream expired after %i msec\n", timeout_network); return 1;
> > }
> > return global_video_state && global_video_state->abort_request;
> >
> > work as well?
> Argh, using timeout_expired is obvious senseless of course...
>
> The time calculation
> av_gettime() - reference_time
> is executed at least once by decode_interrupt_cb(). Therefore I
> disabled the calculation by
> if (timeout_network && ...
> because I expect that timeout_network will be rarely set. But I prefer
> your proposal.
>
> > here timeout_network could be set to UINT64_MAX for the disabled
> > case
> Ok, done. I add opt_timeout_network() to check boundaries from 0 to
> UINT64_MAX. A problem arises while checking latter limit by
> parse_number_or_die() because the function compares the boundaries
> after a double cast. This results in an upper limit which may be
> greater than UINT64_MAX caused by the limited precision of double.
> Therefore I reduced the maximum boundary to UINT64_MAX-20000 to
> guarantee always being less than UINT64_MAX after the double cast.
>
> At the moment I have no idea to calculate the largest double value
> which is <=UINT64_MAX. I tested that the difference between the 2
> subsequent double values at UINT64_MAX is 2048 (double1 < UINT64_MAX <
> double2). Therefore UINT64_MAX-2049 could be sufficient instead of
> UINT64_MAX-20000.
>
> The solution doesn't reject input values for the new command line
> option nto being above the upper limit between the range
> 18446744073709531137 and the subsequent double value because the range
> equals 1 double value. Therefore no matter.
>
> Many thanks for support and I'm sorry for my late response, I was
> quite busy.
> Hagen
> doc/ffplay-doc.texi | 2 ++
> ffplay.c | 17 +++++++++++++++++
> 2 files changed, 19 insertions(+)
> c6a6ff95bda4b3470da1277580ff0111620a8227 patch.diff
iam fine with the patch as soon as the other developers are
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- 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/20091116/1d2d8638/attachment.pgp>
More information about the ffmpeg-devel
mailing list