[FFmpeg-devel] Behaviour of url_read_complete

[Reimar Döffinger]

On Sun, Jan 24, 2010 at 06:59:33AM -0800, Art Clarke wrote:
> > > Protocol handler to not use url_read_complete(...) so it works for
> > > non-blocking I/O
> >
> > Making it not use it everywhere I think would make things really ugly.
> > As I understand it, the point of url_read_complete is exactly _not_
> > having to do that kind of checks all over the place.
> > Though it might be enough to just replace it at some strategic points...
> Using url_read_complete certainly makes the RTMP Protocol code easier to
> maintain -- however it also makes the protocol handler not scale as well
> (i.e. you really need to dedicate a thread per URLContext).  I'm not sure
> yet whether I'll address that -- we're unlikely to be demuxing more than 10
> RTMP streams at a time, and so a thread per each is probably doable.   I'll
> know in a week or two.

You could place your own buffering URLContext in-between, allowing you both
to buffer enough to either only call the rtmp functions when you are reasonably
sure to have enough data  and you can run your own tasks from its read functions.
However I suspect that might become more complex and fragile than just using
a separate thread for each - basically that is the same situation as for all
cases of threaded blocking I/O vs. async I/O I guess :-)