[PATCH] Support Ctrl+Break in ffmpeg.exe on Windows as if it was Ctrl+C
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). (I've also submitted this as a ticket at https://ffmpeg.org/trac/ffmpeg/ticket/1463 but it was recommended I post it here also.)
On 19 Jun 2012, at 11:31, Joe Wreschnig <joe.wreschnig@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).
On Tue, Jun 19, 2012 at 7:10 PM, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
On 19 Jun 2012, at 11:31, Joe Wreschnig <joe.wreschnig@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"?
Win2k and everything since then. (Except maybe WinMe?) Versions before that should work as before - meaning they won't support Ctrl+Break but will still support Ctrl+C via the POSIX compatibility that makes SIGINT work on Windows.
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).
I was copying the pattern already used in the file, e.g. for GetProcessTimes and GetProcessMemoryInfo. GetProcAddress wouldn't really change the #ifdefs. They'd just change it to #ifdef _WIN32s but with more complicated logic.
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@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) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates
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@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 ,.. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth.
On 7/5/12, Michael Niedermayer <michaelni@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@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. Cheers! -roger-
On Wed, Jun 24, 2015 at 04:19:38AM -0600, Roger Pack wrote:
On 7/5/12, Michael Niedermayer <michaelni@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@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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better.
On 6/24/15, Michael Niedermayer <michaelni@gmx.at> wrote:
On Wed, Jun 24, 2015 at 04:19:38AM -0600, Roger Pack wrote:
On 7/5/12, Michael Niedermayer <michaelni@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@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!
On Wed, Jun 24, 2015 at 11:48:10PM -0600, Roger Pack wrote:
On 6/24/15, Michael Niedermayer <michaelni@gmx.at> wrote:
On Wed, Jun 24, 2015 at 04:19:38AM -0600, Roger Pack wrote:
On 7/5/12, Michael Niedermayer <michaelni@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@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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
On 6/25/15, Michael Niedermayer <michaelni@gmx.at> wrote:
On Wed, Jun 24, 2015 at 11:48:10PM -0600, Roger Pack wrote:
On 6/24/15, Michael Niedermayer <michaelni@gmx.at> wrote:
On Wed, Jun 24, 2015 at 04:19:38AM -0600, Roger Pack wrote:
On 7/5/12, Michael Niedermayer <michaelni@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@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-
On Mon, Jun 29, 2015 at 11:09:14PM -0600, Roger Pack wrote:
On 6/25/15, Michael Niedermayer <michaelni@gmx.at> wrote:
On Wed, Jun 24, 2015 at 11:48:10PM -0600, Roger Pack wrote:
On 6/24/15, Michael Niedermayer <michaelni@gmx.at> wrote:
On Wed, Jun 24, 2015 at 04:19:38AM -0600, Roger Pack wrote:
On 7/5/12, Michael Niedermayer <michaelni@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@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
On Mon, Jun 29, 2015 at 11:09:14PM -0600, Roger Pack wrote: [...]
+ Sleep(0);
the funky line ending is here [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras
On 6/30/15, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Jun 29, 2015 at 11:09:14PM -0600, Roger Pack wrote:
[...]
+ Sleep(0);
the funky line ending is here
OK try this one. thanks!
On Tue, Jun 30, 2015 at 01:00:22PM -0600, Roger Pack wrote:
On 6/30/15, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Jun 29, 2015 at 11:09:14PM -0600, Roger Pack wrote:
[...]
+ Sleep(0);
the funky line ending is here
OK try this one. thanks!
configure | 2 ++ ffmpeg.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+) ff3f339e550dc83d300346ec648f778f85900679 0001-windows-respond-to-logoff-and-ctrl-break-messages-as.patch From 7ce401dbd16873928bd541d5d567208963b85889 Mon Sep 17 00:00:00 2001 From: rogerdpack <rogerpack2005@gmail.com> Date: Tue, 30 Jun 2015 12:58:43 -0600 Subject: [PATCH] windows: respond to logoff and ctrl+break messages as well
Signed-off-by: rogerdpack <rogerpack2005@gmail.com> --- configure | 2 ++ ffmpeg.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+)
diff --git a/configure b/configure index 89b5668..cc23991 100755 --- a/configure +++ b/configure @@ -1787,6 +1787,7 @@ SYSTEM_FUNCS=" pthread_cancel sched_getaffinity SetConsoleTextAttribute + SetConsoleCtrlHandler setmode setrlimit Sleep @@ -4990,6 +4991,7 @@ check_func_headers windows.h GetSystemTimeAsFileTime check_func_headers windows.h MapViewOfFile check_func_headers windows.h PeekNamedPipe check_func_headers windows.h SetConsoleTextAttribute +check_func_headers windows.h SetConsoleCtrlHandler check_func_headers windows.h Sleep check_func_headers windows.h VirtualAlloc check_struct windows.h "CONDITION_VARIABLE" Ptr diff --git a/ffmpeg.c b/ffmpeg.c index aac03bb..b58d891 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -79,6 +79,10 @@ #include <windows.h> #include <psapi.h> #endif +#ifdef HAVE_SETCONSOLECTRLHANDLER [...] +#ifdef HAVE_SETCONSOLECTRLHANDLER
they are defined but to 0 on linux, this needs #if [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle
On 6/30/15, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Jun 30, 2015 at 01:00:22PM -0600, Roger Pack wrote:
On 6/30/15, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Jun 29, 2015 at 11:09:14PM -0600, Roger Pack wrote:
[...]
+ Sleep(0);
the funky line ending is here
OK try this one. thanks!
configure | 2 ++ ffmpeg.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+) ff3f339e550dc83d300346ec648f778f85900679 0001-windows-respond-to-logoff-and-ctrl-break-messages-as.patch From 7ce401dbd16873928bd541d5d567208963b85889 Mon Sep 17 00:00:00 2001 From: rogerdpack <rogerpack2005@gmail.com> Date: Tue, 30 Jun 2015 12:58:43 -0600 Subject: [PATCH] windows: respond to logoff and ctrl+break messages as well
Signed-off-by: rogerdpack <rogerpack2005@gmail.com> --- configure | 2 ++ ffmpeg.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+)
diff --git a/configure b/configure index 89b5668..cc23991 100755 --- a/configure +++ b/configure @@ -1787,6 +1787,7 @@ SYSTEM_FUNCS=" pthread_cancel sched_getaffinity SetConsoleTextAttribute + SetConsoleCtrlHandler setmode setrlimit Sleep @@ -4990,6 +4991,7 @@ check_func_headers windows.h GetSystemTimeAsFileTime check_func_headers windows.h MapViewOfFile check_func_headers windows.h PeekNamedPipe check_func_headers windows.h SetConsoleTextAttribute +check_func_headers windows.h SetConsoleCtrlHandler check_func_headers windows.h Sleep check_func_headers windows.h VirtualAlloc check_struct windows.h "CONDITION_VARIABLE" Ptr diff --git a/ffmpeg.c b/ffmpeg.c index aac03bb..b58d891 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -79,6 +79,10 @@ #include <windows.h> #include <psapi.h> #endif +#ifdef HAVE_SETCONSOLECTRLHANDLER [...] +#ifdef HAVE_SETCONSOLECTRLHANDLER
they are defined but to 0 on linux, this needs #if
OK see attached, thanks. -roger-
On Tue, Jun 30, 2015 at 04:33:35PM -0600, Roger Pack wrote:
On 6/30/15, Michael Niedermayer <michaelni@gmx.at> wrote:
On Tue, Jun 30, 2015 at 01:00:22PM -0600, Roger Pack wrote:
On 6/30/15, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Jun 29, 2015 at 11:09:14PM -0600, Roger Pack wrote:
[...]
+ Sleep(0);
the funky line ending is here
OK try this one. thanks!
configure | 2 ++ ffmpeg.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+) ff3f339e550dc83d300346ec648f778f85900679 0001-windows-respond-to-logoff-and-ctrl-break-messages-as.patch From 7ce401dbd16873928bd541d5d567208963b85889 Mon Sep 17 00:00:00 2001 From: rogerdpack <rogerpack2005@gmail.com> Date: Tue, 30 Jun 2015 12:58:43 -0600 Subject: [PATCH] windows: respond to logoff and ctrl+break messages as well
Signed-off-by: rogerdpack <rogerpack2005@gmail.com> --- configure | 2 ++ ffmpeg.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+)
diff --git a/configure b/configure index 89b5668..cc23991 100755 --- a/configure +++ b/configure @@ -1787,6 +1787,7 @@ SYSTEM_FUNCS=" pthread_cancel sched_getaffinity SetConsoleTextAttribute + SetConsoleCtrlHandler setmode setrlimit Sleep @@ -4990,6 +4991,7 @@ check_func_headers windows.h GetSystemTimeAsFileTime check_func_headers windows.h MapViewOfFile check_func_headers windows.h PeekNamedPipe check_func_headers windows.h SetConsoleTextAttribute +check_func_headers windows.h SetConsoleCtrlHandler check_func_headers windows.h Sleep check_func_headers windows.h VirtualAlloc check_struct windows.h "CONDITION_VARIABLE" Ptr diff --git a/ffmpeg.c b/ffmpeg.c index aac03bb..b58d891 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -79,6 +79,10 @@ #include <windows.h> #include <psapi.h> #endif +#ifdef HAVE_SETCONSOLECTRLHANDLER [...] +#ifdef HAVE_SETCONSOLECTRLHANDLER
they are defined but to 0 on linux, this needs #if
OK see attached, thanks. -roger-
configure | 2 ++ ffmpeg.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+) 63faac68b3d286a6700cd3bba7b1e7a3bfeb8786 0001-windows-respond-to-logoff-and-ctrl-break-messages-as.patch From 0def0b7c12bf43e384c57ce1c11a45a7fb520430 Mon Sep 17 00:00:00 2001 From: rogerdpack <rogerpack2005@gmail.com> Date: Tue, 30 Jun 2015 16:31:19 -0600 Subject: [PATCH] windows: respond to logoff and ctrl+break messages as well
applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam"
On 24/06/15 7:19 AM, Roger Pack wrote:
+#ifdef HAVE_SETCONSOLECTRLHANDLER +static BOOL WINAPI CtrlHandler(DWORD fdwCtrlType) +{ + av_log(NULL, AV_LOG_DEBUG, "\nReceived windows signal %d\n", fdwCtrlType); + + switch (fdwCtrlType) + { + case CTRL_C_EVENT: + case CTRL_BREAK_EVENT: + sigterm_handler(SIGINT); + return TRUE; + + case CTRL_CLOSE_EVENT: + case CTRL_LOGOFF_EVENT: + case CTRL_SHUTDOWN_EVENT: + sigterm_handler(SIGTERM); + return TRUE; + + default: + av_log(NULL, AV_LOG_ERROR, "Received unknown windows signal %d\n", fdwCtrlType); + return FALSE; + } +} +#endif + void term_init(void) { #if HAVE_TERMIOS_H @@ -358,6 +386,9 @@ void term_init(void) #ifdef SIGXCPU signal(SIGXCPU, sigterm_handler); #endif +#ifdef HAVE_SETCONSOLECTRLHANDLER + SetConsoleCtrlHandler((PHANDLER_ROUTINE)CtrlHandler, TRUE); +#endif
Why ffmpeg only? Can't this be in cmdutils.c to also work with the other tools?
On 6/25/15, James Almer <jamrial@gmail.com> wrote:
On 24/06/15 7:19 AM, Roger Pack wrote:
+#ifdef HAVE_SETCONSOLECTRLHANDLER +static BOOL WINAPI CtrlHandler(DWORD fdwCtrlType) +{ + av_log(NULL, AV_LOG_DEBUG, "\nReceived windows signal %d\n", fdwCtrlType); + + switch (fdwCtrlType) + { + case CTRL_C_EVENT: + case CTRL_BREAK_EVENT: + sigterm_handler(SIGINT); + return TRUE; + + case CTRL_CLOSE_EVENT: + case CTRL_LOGOFF_EVENT: + case CTRL_SHUTDOWN_EVENT: + sigterm_handler(SIGTERM); + return TRUE; + + default: + av_log(NULL, AV_LOG_ERROR, "Received unknown windows signal %d\n", fdwCtrlType); + return FALSE; + } +} +#endif + void term_init(void) { #if HAVE_TERMIOS_H @@ -358,6 +386,9 @@ void term_init(void) #ifdef SIGXCPU signal(SIGXCPU, sigterm_handler); #endif +#ifdef HAVE_SETCONSOLECTRLHANDLER + SetConsoleCtrlHandler((PHANDLER_ROUTINE)CtrlHandler, TRUE); +#endif
Why ffmpeg only? Can't this be in cmdutils.c to also work with the other tools?
It basically piggy backs on the existing signal handling code, which I guess is FFmpeg only (probably each process needs to setup their own signal handling). At least it'll be a nice example for people to use if they need to :) -roger-
participants (5)
-
James Almer -
Joe Wreschnig -
Michael Niedermayer -
Reimar Döffinger -
Roger Pack