[FFmpeg-devel] Behaviour of url_read_complete

[Art Clarke]

On Sun, Jan 24, 2010 at 1:41 AM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de>wrote:

> On Sat, Jan 23, 2010 at 08:52:59PM -0800, Art Clarke wrote:
> > So your patch is right -- but people shouldn't use url_read_complete(...)
> if
> > they want to do non-blocking socket I/O.
>
> If you want to do that you would have to have support for resuming a read
> anyway, so what would be the advantage of using url_read_complete?
> And please if you have suggestions for improving the documentation say so.
>
>
No, the doc is complete and correct.


> > 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.

-- 
http://www.xuggle.com/
xu?ggle (z?' gl) v. To freely encode, decode, and experience audio and
video.

Use Xuggle to get the power of FFmpeg in Java.