[FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer
george at nsup.org
Fri Jul 8 22:51:56 EEST 2016
Le primidi 21 messidor, an CCXXIV, Jan Sebechlebsky a écrit :
> I actually thought about this and maybe I am still missing something, but
> how is this different from the situation without FIFO muxer?
It is not, which is exactly the answer you do not want when people ask what
your program is good for.
> When the FIFO is not used, let's say an I/O operation somewhere inside
> write_packet call blocks for a long time - actually it means it is spinning
> in a cycle "wait for io with short timeout"<->"check return value of
> interrupt callback". When the application decides to interrupt the
> operation, it sets some interrupt condition (ffmpeg increments
> received_nb_signals when receives SIGINT). The next call to interrupt
> callback will cause the IO function to return AVERROR_EXIT causing
> write_packet to fail with same error.
> When the FIFO is used the write_packet call will return immediately. The I/O
> blocking will happen in consumer thread, in some of the
> fifo_thread_write_packet calls. Let's say that during that time all packets
> are send to queue and write_trailer is called. The main thread
> is blocked by pthread_join(). However when the interrupt condition is set
> (for example by receiving SIGINT as in ffmpeg), this is still handled by the
> blocking IO function which will return AVERROR_EXIT causing
> fifo_thread_write_packet to fail with the same error, causing the thread to
> terminate which unblocks write_trailer.
> My point is that the same asynchronous mechanism which is supposed to work
> in case of blocking I/O operation should work also in case pthread_join is
> blocking, so the I/O operation should be terminated the same way returning
> AVERROR_EXIT which will cause consumer thread to terminate and unblock
> pthread_join call...
> Am I missing something?
I think you are missing (not in the sense of your question) a clear mission
statement for the FIFO muxer. Or, to put another way, a detailed explanation
of what it is useful for and more importantly, how to benefit from it.
If I understand things correctly, it is meant to be used by applications (or
libraries, including the tee muxer), not directly by users. But how are the
applications supposed to do exactly, and what can they expect.
One of the features seems to be to turn a blocking muxer into a non-blocking
muxer, which is indeed useful. But if the muxer falls back to blocking on
close and the application needs to set up a thread-synchronized interrupt
callback to handle it, then I feel we are missing a serious opportunity.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the ffmpeg-devel