[FFmpeg-devel] [PATCH] ffmpeg.c: use sigterm_handler with sigpipe
sw at jkqxz.net
Thu Jan 18 17:55:33 EET 2018
On 18/01/18 14:49, Dave Rice wrote:
> Thread bump.
>> On Jan 11, 2018, at 5:51 PM, Nicolas George <george at nsup.org> wrote:
>> Moritz Barsnick (2018-01-11):
>>> This patch doesn't change the handling of SIGTERM
>> You should have read SIGPIPE, obviously.
>>> Is SIGPIPE an interactive signal?
>> Of course not.
>>> Anything on the other side of output
>>> file(name) "-" or "pipe:N" may terminate for some reason.
>> Yes, that is exactly what SIGPIPE is for.
>>> This patch does NOT try to ignore anything. ffmpeg won't keep running
>>> due to ignoring of SIGPIPE, it will terminate more cleanly due to
>>> handling it. The former is not desired. (But yes, shall handing to
>>> enforce ignoring it would allow that.)
>> It will terminate less cleanly than if you do the right thing with
> This patch has been working for me and ffmpeg terminates cleanly with SIGPIPE with a valid output (moov atom written with mov or cues/seekhead written with mkv). Not sure if I understand well the disadvantage of this patch.
Making SIGPIPE have an effect like this seems highly dubious to me, but I admit that since it always killed the process before it feels like an improvement.
Changing it to ignore the signal (set it to SIG_IGN) instead sounds like a safer option? I think that would move the code to having the same behaviour on Unices as on Windows, since Windows has no SIGPIPE.
Setting the termination option in the ffmpeg program or not shouldn't make a difference to the behaviour inside the muxer - the failing call is still going to return and the error propagated to its caller like it is already on Windows, so that handling has to work anyway. If there is a case where a subsequent call causes problems which are somehow different between Unix/Windows such that ignoring the signal does not make them act similarly then that is a bug which should be fixed.
More information about the ffmpeg-devel