On Tue, 12 Jul 2016, Nicolas George wrote:
Le quintidi 25 messidor, an CCXXIV, Marton Balint a écrit :
The fifo muxer never returns EAGAIN. It silently drops the packets in
non-blocking mode on a full queue. This behaviour is useful for the tee
muxer case, when you don't want one slow/unreliable (network) output to
block reading the input, therefore blocking fast outputs (disk) as well.
Wait a minute. This is way to specific to be the default behaviour, let
alone the only one.
As far as I know, in the current API, if the user gets a negative return
value from av_write_frame(), it should be handled as a fatal error. EAGAIN
is not handled/interpreted specially. The same is true for
av_write_trailer(), and calling av_write_trailer - regardless of the return
value - frees all private resources for the context as well, so you cannot
change the semantics of av_write_trailer to not free private data in case of
EAGAIN, because it would cause unfreed data for legacy users.
You are wrong. Returning EAGAIN so that the caller try again later is the
normal behaviour for muxers that support non-blocking operation. I grant you
that there are only between one and three of them, but still, that is how
they work.
And that is also how they are supposed to work, because that is how
non-blocking protocols work, and also how non-blocking works outside FFmpeg.
Please point me to an application which uses ffmpeg non-blocking mode like
it is supposed to be used. I don't see any muxers wich return EAGAIN, only
protocols, and they only return EAGAIN if AVIO_FLAG_NONBLOCK is set. I
wonder how that can work for av_write_trailer, because - as I mentioned
earlier -, av_write_trailer must free private data, so you simply cannot
call it multiple times.
Prove me wrong, but I have a feeling that the current AVIO_FLAG_NONBLOCK
mode in ffmpeg was mostly tested for input, never for output, it does
not work properly for output, and to be frank I don't want to get into
fixing it, when our goals can be achieved without dealing with this
problem.
Therefore I would like to keep the fifo muxer as Jan submitted it, without
EAGAIN support. If there is a use case for non-blockingingness in a sense
you use the phrase, then it can be added later.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
