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

[Nicolas George]

Le quintidi 25 messidor, an CCXXIV, Marton Balint a écrit :
> 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.

Yes, it does not work. That is exactly the problem. Non-blocking mode never
worked except for the low-level protocols (TCP, UDP) and a few devices. I
can therefore not show you any application that use it, they do not exist.

But non-blocking mode is important. Except for very simple applications,
blocking mode is unusable. The only solution right now is for the
application to use threads, and threads are very tricky to use, both because
of portability concerns (see all the framework in FFmpeg to handle several
threads implementations and all the trouble it has caused in the past) and
because of the difficulty of implementing the communication without bugs and
race conditions.

The FIFO muxer, if implemented correctly, could be a big first step towards
providing a working non-blocking mode.

Regarding the issue of returning EAGAIN from write_trailer(), you have to
realize that the few devices that actually work in non-blocking mode (I can
vouch for ALSA, I suspect a few other work too), blocking cannot happen in
the close phase, and therefore returning EAGAIN there is not necessary.

But since other muxers could block there the case must be handled. Returning
EAGAIN and not freeing everything is the only sane way to do it.

I grant you that it would require an API for aborting-and-freeing
immediately. This is not very hard to do, and is actually useful in its own
self.

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

I am against it. As it is, I consider it is way too specific to be added to
the code base.

Implementing the FIFO muxer correctly, on the other hand, would by far
overshadow anything that could be done on the tee muxer in the foreseeable
future. And since the work it requires on top of what Jan already did is
rather small, I really do not understand why you are fighting against it.

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/20160715/95c1e082/attachment.sig>