[FFmpeg-devel] [PATCH] Support Ctrl+Break in ffmpeg.exe on Windows as if it was Ctrl+C

[Roger Pack]

On 6/24/15, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Wed, Jun 24, 2015 at 04:19:38AM -0600, Roger Pack wrote:
>> On 7/5/12, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Mon, Jun 25, 2012 at 02:21:21PM +0200, Michael Niedermayer wrote:
>> >> On Tue, Jun 19, 2012 at 07:10:04PM +0200, Reimar Döffinger wrote:
>> >> > On 19 Jun 2012, at 11:31, Joe Wreschnig <joe.wreschnig at gmail.com>
>> >> > wrote:
>> >> > > On Windows, the Ctrl+Break key combination usually does what
>> >> > > Ctrl+C
>> >> > > does. It is more common for processes to send other processes
>> >> > > Ctrl+Break rather than Ctrl+C, because sending Ctrl+C / SIGINT
>> >> > > doesn't
>> >> > > work if you started a child in a new process group.
>> >> > >
>> >> > > This patch makes ffmpeg.exe register what Windows calls a console
>> >> > > control event handler, which allows it to intercept Ctrl+Break. It
>> >> > > hands it off directly to the usual SIGINT/SIGTERM handler. The
>> >> > > same
>> >> > > function also processes closing the console window, mapping it to
>> >> > > SIGTERM.
>> >> > >
>> >> > > Obviously, this is only enabled if compiling for a platform where
>> >> > > SetConsoleCtrlHandler is available (i.e. modern Windows).
>> >> >
>> >> > What is "modern"? Also it is rather unusual to recompile for
>> >> > different
>> >> > Windows versions, couldn't you with about the same effort just use
>> >> > GetProcAddress (more complex code, but in exchange you'd save on all
>> >> > the
>> >> > configure changes and #ifs).
>> >>
>> >> It seems versions that dont support this are no longer supported
>> >> by microsoft. IMHO we shouldnt bother too much with such old windows
>> >> versions unless someone wants to / volunteers to do it.
>> >>
>> >> thus, if there are no objections i will apply this patch once a few
>> >> minor issues are fixed (ifdef breaking compile to be precisse)
>> >
>> > iam waiting for a working patch
>> > i could try to fix it before applying myself but with patches for
>> > non linux platforms i prefer to avoid changing as the changes would
>> > be untested ,..
>>
>> Sorry I dropped the ball on this one.
>> See attached.  The major gains we get out of this (in my head at
>> least) is hopefully better shutdown if somebody logs out (which has
>> bitten me before).  Or if someone closes a console window which also
>> shuts down FFmpeg.
>>
>> I noticed that even with handling notifications of "logout" that
>> ffmpeg can still easily leave behind corrupted mp4 files (it gets
>> killed quickly after).
>
>> Makes me wonder if there's some way to make it shutdown more quickly,
>> but I'm not sure if it's a problem yet or not.
>
> iam not sure i understand ?
> does windows kill the process immedeatly after CtrlHandler() returns?
> if so CtrlHandler() should wait for the main loop to exit and cleanup
> finishing before it returns

Thanks for the pointer, you were exactly right.  Appears I can
basically "Sleep" in that method and thus allow FFmpeg to cleanup (in
vista+ I believe it gives a max of 5 seconds which is enough).  If
there's some other easy way to know the main loop has exited I could
use that I suppose, but it should have the same effect.

See attached revision (it now writes finalizes files appropriately for
the logoff/close messages).
Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-windows-respond-to-logoff-and-ctrl-break-messages.patch
Type: application/octet-stream
Size: 2781 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150624/a3f27ca9/attachment.obj>