[FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer
Marton Balint
cus at passwd.hu
Wed Jul 13 00:09:59 EEST 2016
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
More information about the ffmpeg-devel
mailing list