On Sun, May 1, 2011 at 19:43, Martin Storsjö <[email protected]> wrote:
> 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 specifically, I am talking about mpegts over udp. currently av_open_input_file can hang in the probing stage because of blocking udp. url_interrupt_cb<http://libav.org/doxygen/master/group__old__url__funcs.html#g6bad928f5639acd1d8ffcff648f5ed2f> is not a good api to handle this because it stops *all *active streams instead of a specific one. -- Aviad Rozenhek
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
