[FFmpeg-devel] Behaviour of url_read_complete

[Art Clarke]

On Sat, Jan 23, 2010 at 9:23 AM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de>wrote:

> 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 :-)
>

You know, I think you have.  The issue I mentioned is still somewhat valid
-- your loop on EAGAIN means threads that call url_read_complete(...) block
now until they are fully complete (or get a different error) -- which means
you can't use url_read_complete for non-blocking I/O.  Setting
url_set_interrupt_cb (which I do set) still requires a timeout, and in
non-blocking I/O I want to do something else useful with the thread rather
than ask my OS to park it.

But the prior code (before you patched it) could lead to corrupted packets
sometimes -- and that may have been a separate bug I was trying to track
down.  Your change did change our performance characteristics for RTMP
streams -- because the old url_read_complete(...) would return control back
on EAGAIN letting other (not libav tasks) work on the thread, but hell, I'll
take a small performance hit if it fixes incorrect data.

So your patch is right -- but people shouldn't use url_read_complete(...) if
they want to do non-blocking socket I/O.  I may submit a patch to the RTMP
Protocol handler to not use url_read_complete(...) so it works for
non-blocking I/O, but for now I agree, forget that other crazy patch I put
together.

- Art

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