On Mon, Jun 29, 2015 at 11:09:14PM -0600, Roger Pack wrote: > On 6/25/15, Michael Niedermayer <michae...@gmx.at> wrote: > > On Wed, Jun 24, 2015 at 11:48:10PM -0600, Roger Pack wrote: > >> On 6/24/15, Michael Niedermayer <michae...@gmx.at> wrote: > >> > On Wed, Jun 24, 2015 at 04:19:38AM -0600, Roger Pack wrote: > >> >> On 7/5/12, Michael Niedermayer <michae...@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.wresch...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
