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

[Roger Pack]

On 6/25/15, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Wed, Jun 24, 2015 at 11:48:10PM -0600, Roger Pack wrote:
>> 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.
>
> you could set a global volatile variable to 1 at the end of
> exit_program() and wait on that to happen in the handler

Interesting.  I think it's probably "the same finally behavior" either
way, since exit will be called, and the entire process basically
terminated, but it does feel cleaner slightly.
.
Attached is one that waits on a variable set in ffmpeg_cleanup (since
I guess that's run after exit() is called?) if you like it more.  Feel
free to modify it to fit.

In my experiments typically the process is terminated before it even
has a chance to get past the Sleep(0) loop, but sometimes it does :)

Cheers!
-roger-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-windows-respond-to-logoff-and-ctrl-break-messages-as.patch
Type: application/octet-stream
Size: 3167 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150629/307e92b5/attachment.obj>