[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