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

Nicolas George george at nsup.org
Mon Jul 11 13:24:43 EEST 2016


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 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.

> >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.

(Speaking of API changes and syntactic sugar, a function to create a FIFO
muxer from an existing AVFormatContext would probably be useful: it would
avoid all the trouble with options, re-parsing, etc.)

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160711/8a2d9f78/attachment.sig>


More information about the ffmpeg-devel mailing list