[FFmpeg-cvslog] r22718 - trunk/libavformat/rtsp.c

[Martin Storsjö]

On Mon, 29 Mar 2010, Reimar D?ffinger wrote:

> On Mon, Mar 29, 2010 at 10:41:50PM +0300, Martin Storsj? wrote:
> > On Mon, 29 Mar 2010, Reimar D?ffinger wrote:
> > 
> > > On Mon, Mar 29, 2010 at 03:23:38PM -0400, Ronald S. Bultje wrote:
> > > > On Mon, Mar 29, 2010 at 3:21 PM, Reimar D?ffinger
> > > > <Reimar.Doeffinger at gmx.de> wrote:
> > > > > I missed the discussion, but in addition I wonder why we have some
> > > > > arbitrary timeout here instead of checking the interrupt callback.
> > > > > A fixed timeout is always going to be far too high for some and far too
> > > > > low for others.
> > > > 
> > > > interrupt callback is called at the beginning of the loop, it is
> > > > there, just not visible in this particular part of the patch.
> > > 
> > > But why then a second timeout mechanism?
> > > Or does the specification explicitly say that a stream
> > > may not stop sending for more than x seconds?
> > 
> > url_interrupt_cb() is global and stops all reads in the whole process
> 
> That is an issue, though the better solution to that would be to improve
> the API, e.g. by passing context to the callback maybe?

Yes, that would indeed be a better design.

> > (and 
> > needs a separate thread to check for a timeout)
> 
> Huh? I can't see why that would be necessary.

Nevermind, it was a brain fart...

> > whereas this makes a 
> > av_read_frame() call return within reasonable time, which could earlier 
> > block infinitely if the sender had died.
> 
> Well, I can see the point now, though it's at the expense of anyone who'd like
> to wait more than 10 seconds...

Yes, true. Although not perfect, it's a small improvement to how things 
were before.

// Martin