On 18/01/18 14:49, Dave Rice wrote:
> Thread bump.
> 
>> On Jan 11, 2018, at 5:51 PM, Nicolas George <geo...@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
>> SIGPIPE.
> 
> 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.

- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to