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

[Michael Niedermayer]

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>