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. See attached revision (it now writes finalizes files appropriately for the logoff/close messages). Thanks!
0001-windows-respond-to-logoff-and-ctrl-break-messages.patch
Description: Binary data
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
