[FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer

[Marton Balint]

On Mon, 11 Jul 2016, Nicolas George wrote:

> Le primidi 21 messidor, an CCXXIV, Marton Balint a écrit :
>> The basic goals are the ones which are set in the GSOC trac page under the
>> tee muxer improvement project:
>>
>> Description: FFmpeg contains a tee muxer, which is capable of writing the
>> same coded packets to multiple outputs. However, if one of the outputs
>> blocks or fails for any reason, the other outputs will block or fail too.
>> Also there is no built-in support for gracefully restarting an output in
>> case of a failure. Lacking these two features makes the tee muxer unsuitable
>> for redundancy or high availability purposes especially on networked
>> outputs.
>>
>> Expected results:
>> •Add a non-blocking mode with a configurable maximum packet queue size where
>> one output does not block the others
>> •Add a graceful restart mode where a failed output can transparently
>> automatically restart its operation
>>
>> We decided to implement these features in a separate muxer, instead of hard
>> coding it to tee, but the goals are the same. In order to reach them, one
>> will have to specify fifo muxers in the output of the tee muxer, or Jan can
>> work on some syntactic sugar which makes this more convenient for the user,
>> but the result is the same.
>
> As you say, these are the basic goals. At some point, the goals must become
> more detailed: exact API, exact requirements on the application, etc. It can
> often be part of the implementation¹, but when the implementation is tricky,
> stating the detailed goals separately helps.
>
>> It also can be used by users. For example in blocking mode the fifo muxer
>> can work as a pipeline between the encoder and the output, hiding disk
>> latencies. In this scenario the user don't need to use the tee muxer to grab
>> the benefits of the fifo muxer. In this case, it works similarly as the
>> async protocol for input, only for output.
>
> Indeed. Non-blocking mode, OTOH, can only be useful for applications, unless
> I am mistaken: otherwise, the applications would get EAGAIN they do not
> expect and treat it as a fatal error.

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.

>
>> The reason why neither me (and I guess nor Jan) sees this as an issue, is
>> that this is not needed for the goals set in the project. We simply don't
>> care if closeing a stream blocks, that is not what we are aiming for here.
>
> If the goals state "non-blocking" and closing is still blocking, you can not
> say the goals were achieved. You can of course decide to downgrade the goals
> or to leave some of them for later, but you cannot just ignore the issue.
>

Yes, apparently we should improve the documentation for the fifo muxer use 
cases.

>>> The way I see it, in non-blocking mode, the most logical approach would be
>>> something like this: the first call to write_header() causes the closing
>>> process to start an returns EAGAIN immediately, subsequent calls return
>>> EAGAIN until the closing process is done, then 0 for success, or an error
>>> code after a configurable timeout.
>> Sure, this can be implemented (although an API change, so dificcult to pull
>> through), but in GSOC this was simply not a goal of ours.
>
> What I describe is not an API change at all, it is the obvious way for
> non-blocking mode to work.

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.

If anybody wants an API which can return EAGAIN for 
write_frame/write_trailer IMHO, it should be separate from the existing 
calls.

The fifo muxer does not change the semantics of these calls, yet it 
achieves the goals which are originally set.

I hope this makes sense, I feel there was some misunderstanding.

Regards,
Marton