On Sun, 1 May 2011, aviad rozenhek wrote:
> On Sun, May 1, 2011 at 16:04, Ronald S. Bultje <[email protected]> wrote:
> > We need a demuxer-supports-nonblock (or doesnotsupport-nonblock) flag
> > so we can turn it off for the demuxers not supporting it.
>
> doesn't retry_transfer_wrapper() already take care of this without requiring
> explicit support in demuxers?
No - what retry_transfer_wrapper does is makes a nonblocking protocol
(that is, one that can return AVERROR(EAGAIN)) blocking, unless the
nonblocking flag is set.
However, for this to be useful, all demuxers that read data need to be
ready to handle an AVERROR(EAGAIN) at any point. E.g., imagine a normal
demuxer reading a packet from a TCP stream. Halfway through the packet,
the input AVIO returns AVERROR(EAGAIN) - then the demuxer would have to
store the halfway parsed packet internally, return AVERROR(EAGAIN) to the
caller, and resume parsing the packet on the next av_read_frame() call.
(Rewinding the AVIO would be one way of dealing with this a bit simpler,
but wouldn't work if the start of the packet has been flushed from the
AVIO buffer.)
If you think of datagram inputs, then you normally don't have the same
issue - if you get some data, you usually get the full packet. But for
byte streams, you can't count on this, the EAGAIN returns from the IO
doesn't correspond to packet boundaries in the container that is streamed
at all.
Which demuxer and protocol did you want to use it with more concretely, in
this case?
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
