[FFmpeg-devel] [PATCH] remove loop in udp_read

[Martin Storsjö]

On Thu, 16 Sep 2010, aviad rozenhek wrote:

> the file udp.c provides a very useful API for handling udp traffic,
> specifically I use it for handling raw mpegts packets.
> however the fact the udp_read blocks forever makes it less useful in case no
> traffic comes in.
> 
> I modified udp_read to return AVERROR(EAGAIN) in case there is currently no
> data available,
> and compensated for that by looping in two places in aviobuf.c

While I do agree that proper nonblocking IO support would be good, the 
attached patch is an extremely hackish solution that isn't acceptable as 
such.

I also do agree that interrupt_cb isn't suitable in its current form for 
custom timeouts for individual streams, but it works well for finishing 
and cleaning up leftover streams on process shutdown.

The design of the URLProtocols currently is that all reads are blocking - 
changing this for one protocol is inconsistent and may break other 
applications relying on the current behaviour, if they're using 
URLContexts directly without wrapping it in a ByteIOContext, that's a very 
big no-no to me.

Also, the patch you suggest wouldn't make the UDP protocol truly 
nonblocking, it would still block for an arbitrary time (100 ms at the 
moment) until it returns AVERROR(EAGAIN).

Ideally, one would be able to select whether nonblocking mode is desired 
or not, depending on what the caller wants. I don't think the 
ByteIOContext routines should retry immediately if EAGAIN is returned, 
since that doesn't help solving the issue of aborting if no data is 
received, that you're trying to solve. But for proper nonblocking reading 
to work in demuxers, they should be ready to handle EAGAIN at any point, 
in the middle of packets, which they don't at the moment.

Would a much simpler way of solving the issue of making the UDP protocol 
not block forever be to add a parameter (either a URL parameter, or a 
proper AVOption parameter - see http.c) that specifies the maximum 
blocking time for this protocol?

// Martin