ffmpeg: Don't trigger url_interrupt_cb on the first signal
diff mbox

Message ID 1306064642-92894-1-git-send-email-martin@martin.st
State Committed
Commit a121754852a69b4879a39ba78863404c13c54f61
Headers show

Commit Message

Martin Storsjö May 22, 2011, 11:44 a.m. 
Currently, the url_interrupt_cb callback will abort all IO
after the first received signal. This makes the output files
from e.g. the mov muxer to be unreadable if the transcode is
aborted with ctrl+c.

After this patch, the first signal cleanly breaks out of
the transcoding loop, but won't forcibly abort all IO.
After the second signal is received, the url_interrupt_cb
callback will abort all IO.
---
 ffmpeg.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

Comments

Luca Barbato May 22, 2011, 11:51 a.m. | #1 
On 5/22/11 1:44 PM, Martin Storsjö wrote:
> Currently, the url_interrupt_cb callback will abort all IO
> after the first received signal. This makes the output files
> from e.g. the mov muxer to be unreadable if the transcode is
> aborted with ctrl+c.
>
> After this patch, the first signal cleanly breaks out of
> the transcoding loop, but won't forcibly abort all IO.
> After the second signal is received, the url_interrupt_cb
> callback will abort all IO.
> ---
>   ffmpeg.c |    4 +++-
>   1 files changed, 3 insertions(+), 1 deletions(-)

The patch looks ok, the description might be clarified or the callback 
renamed since IO and decode do not feel the same.

lu

Patch
diff mbox 

diff --git a/ffmpeg.c b/ffmpeg.c
index 0c95451..8673253 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -426,11 +426,13 @@  static void term_exit(void)
 }
 
 static volatile int received_sigterm = 0;
+static volatile int received_nb_signals = 0;
 
 static void
 sigterm_handler(int sig)
 {
     received_sigterm = sig;
+    received_nb_signals++;
     term_exit();
 }
 
@@ -445,7 +447,7 @@  static void term_init(void)
 
 static int decode_interrupt_cb(void)
 {
-    return received_sigterm;
+    return received_nb_signals > 1;
 }
 
 static int ffmpeg_exit(int ret)