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

[Michael Niedermayer]

On Mon, Jun 29, 2015 at 11:09:14PM -0600, Roger Pack wrote:
> 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 :)

does ffmpeg really need >5sec to exit cleanly?
if so it would be interresting to know why it needs so much time

[...]

> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -79,6 +79,10 @@
>  #include <windows.h>
>  #include <psapi.h>
>  #endif
> +#ifdef HAVE_SETCONSOLECTRLHANDLER

#if HAVE_SETCONSOLECTRLHANDLER
otherwise build breaks non non-windows

i also think ive seen a "\M" line ending in the patch somewhere
but my editor ate it so i dunno where it was

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150630/465e92c0/attachment.asc>