[FFmpeg-devel] Tee improvement - discussion
sebechlebskyjan at gmail.com
Fri Jun 3 17:58:43 CEST 2016
On 06/03/2016 03:53 PM, Nicolas George wrote:
> Le nonidi 9 prairial, an CCXXIV, Jan Sebechlebsky a écrit :
>> If I understand it correctly, I think this will be handled quite smoothy -
>> you don't have to kill the blocked write, the application has to call
>> write_trailer anyway before closing the muxer, so I guess this is the place
>> where tee will wait for the muxer's pending write operation to finish. So
>> application will know, that after call to write_trailer all operations are
> There is no "after call to write_trailer": the real muxer is blocked
> writing, it will not terminate. By pushing it in a thread, you may have
> achieved non-blocking writes for the application, but that just pushed the
> issue a bit further.
> To achieve real non-blocking operation, you need to have all the muxers and
> protocols stack working in non-blocking mode, or you need asynchronous
> killing of I/O operations. Asynchronous killing of I/O operations exists,
> that is pthread_cancel(), but it is quite tricky to use and we had no end of
> portability issues with it too.
I guess then, that implementing it without killing blocked threads
should not introduce any new problems - the process will hang as it does
now in this kind of situation.
I can try to take a look if canceling the thread could be used. How
do you imagine this (like that there will be a timeout enforced by
killing the thread?). Do you know where are I/O operations which can
block forever without timeouting used, so I can try to take a look at
some particular case?
More information about the ffmpeg-devel