[FFmpeg-devel] [PATCH] ffmpeg: modify tty state when stderr is redirected

[Ganesh Ajjanagadde]

On Mon, Aug 3, 2015 at 10:40 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> On Mon, Aug 3, 2015 at 4:34 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>> On Sat, Aug 1, 2015 at 6:54 AM, Nicolas George <george at nsup.org> wrote:
>>> Le quartidi 14 thermidor, an CCXXIII, Michael Niedermayer a écrit :
>>>> > ffmpeg -lavfi testsrc -f framecrc | head
>>>> Thats interresting, i tried this and it did not trash my terminal
>>>> also ive almost never seen ffmpeg trash my terminal with the current
>>>> code. No matter how i run it
>>>
>>> As Ganesh noticed, I forgot the output "-" in my example, but you probably
>>> noticed that on your own, and that is not the issue.
>>>
>>> I just ran some tests and it appears that bash restores the tty state if the
>>> command was killed by a signal but not if it exited normally.
>>>
>>> Therefore, "ffmpeg ... - | head" will have the tty restored because ffmpeg
>>> dies by SIGPIPE, but "strace ffmpeg ... - | head" will trash the tty state
>>> because bash does not know of the SIGPIPE. The same goes for anything that
>>> runs ffmpeg as a sub-process, from "sh -c ..." to the FATE harness.
>>>
>>> Well, bash does part of its job, but I consider it should do more: leaving
>>> the tty trashed just because you inserted strace in front of the command is
>>> bad policy.
>>
>> Above example shows that even without this patch, tty state can be trashed.
>> Thus tty trashing is unavoidable, and only fix for this is via shell
>> configuration (see patch 2/3).
>> Therefore this patch should be included to fix Ticket2964.
>
> Trashing the state even more often just because there is one example
> where this can already happen is not a valid reasoning.

Theoretically it does happen more often.
However, in practice main concern is with make fate.
Patch 3/3 runs fate in noninteractive mode (as it should), removing
this concern.
My point is that no matter what we do, if we want keyboard interactivity,
there will exist use cases where ffmpeg can trash the terminal,
and it is not ffmpeg's responsibility to fix all of these, but the shell's.

>
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel