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

aviad rozenhek aviadr1
Fri Sep 17 23:14:04 CEST 2010


>
>
> The design of the URLProtocols currently is that all reads are blocking -
>

I believe that ByteIOContext is the part responsible for taking care of
buffering and as such it could also take care of EAGAIN errors.

as far as I know in libav* all reading is done through ByteIOContext, so no
harm is done by patch to ffmpeg itself.


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


UDP protocol is useful for working in raw MPEGTS mode which is why I use it
directly.
using ByteIOContext abstracts away the UDP packets and makes data look like
a byte stream which isnt optimal when working with raw MPEGTS.



> 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).
>
>
my next patch would make the sleep timeout configurable per input


> Ideally, one would be able to select whether nonblocking mode is desired
> or not, depending on what the caller wants.


that might make URLs long and complicated ,,,


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


I am not trying to address aborts,
rather I'm trying to enable non-blocking input with UDP.
I need these UDP patches to build more raw MPEGTS over UDP support into
ffmpeg.


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

hmm, this is a much bigger problem than what I'm trying to solve.
from my perspective all demuxers can remain just as they are because they
use ByteIOContext which should take care of any buffering issues for them,


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

the current behavior of blocking forever works well for a commandlne
application such as ffmpeg, I dont want to change that.

thanks for taking the time for review my patches
-- 
Aviad Rozenhek



More information about the ffmpeg-devel mailing list