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

Jan Sebechlebsky sebechlebskyjan at gmail.com
Fri Jul 8 11:56:39 EEST 2016

Hello Nicolas,

On 07/07/2016 08:00 PM, Nicolas George wrote:
> If your worker thread is blocked on an I/O operation when the application
> tries to close the muxer, it will send the corresponding messages and call
> pthread_join(). Since the worker thread is still blocked in the I/O
> operation, it will be stuck like that forever. To avoid that, the main
> thread needs to arrange for the I/O operation to be cancelled
> asynchronously, and that is what the interrupt callbeck is for.
> On the other hand, we do not want to cancel writing the trailer if it is
> just a little slow, so there must be some kind of timeout.
I actually thought about this and maybe I am still missing something, 
but how is this different from the situation without FIFO muxer? Please, 
correct me if I am wrong:

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?

Thank you for your help


More information about the ffmpeg-devel mailing list