[FFmpeg-devel] Behaviour of url_read_complete

[Reimar Döffinger]

On Sat, Jan 23, 2010 at 06:17:21PM +0100, Reimar D?ffinger wrote:
> On Sat, Jan 23, 2010 at 06:08:01PM +0100, Reimar D?ffinger wrote:
> > On Sat, Jan 23, 2010 at 08:07:58AM -0800, Art Clarke wrote:
> > > On Fri, Jan 22, 2010 at 2:25 PM, Reimar D?ffinger
> > > <Reimar.Doeffinger at gmx.de>wrote:
> > > 
> > > > On Fri, Jan 22, 2010 at 07:33:23PM +0100, Reimar D?ffinger wrote:
> > > > > Hello,
> > > > > I am a bit unsure about the purpose of url_read_complete.
> > > > > However I would find it more convenient if its behaviour was as
> > > > > with patch below.
> > > > > What are your opinions?
> > > > > The users of it in FFmpeg I saw would still work with that change.
> > > >
> > > > Here is a proper patch.
> > > >
> > > 
> > > This negatively impacts our Octopus media server (
> > > http://www.xuggle.com/octopus) when reading streaming media.  Our demuxers
> > > share threads with other objects doing work, and when reading network
> > > sources and getting EAGAIN we were using that opportunity to share
> > > (cooperatively) the thread to do other work.  Now, effectively the thread is
> > > blocked doing a hot spin loop on the socket waiting for data which means we
> > > have to move those other jobs on to other threads (which changes our scaling
> > > model as the thread-context switch is not desired).  Under conditions where
> > > a RTMP, RTP or HTTP server we're reading from is temporarily slow, it now
> > > slows down our entire media server very noticeably.  Boo hoo :(
> > 
> > Please explain when where and why this issue appears.
> > With the previous code on encountering a EAGAIN all data received so far
> > would simply have been silently dropped.
> > So my understanding is that you can only have performance issues if before
> > your code never worked right.
> > I am not against reverting this if you can explain what is going on,
> > but I am very reluctant to do it if this probably only uncovers bugs and
> > places where url_read_complete should never have been used.
> 
> And I forgot: to just avoid performance issues, adding a short sleep on EAGAIN
> should help against that while avoiding bugs.

And one more forgot:
you also should be able to abort this loop without modifications in FFmpeg by setting
url_set_interrupt_cb - if that doesn't work IMO that would be a valid bug report.
And of course say if you disagree, but my viewpoint is that I actually helped you
find a otherwise hard to track down bug in your (or possibly some other part of FFmpeg)
code :-)