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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
