#9009: SIGINT ignored while awaiting RTP data
--------------------------------------+----------------------------------
Reporter: Juan Navarro | Owner: (none)
Type: defect | Status: new
Priority: normal | Component: ffmpeg
Version: git-master | Resolution:
Keywords: sigint, exit | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
--------------------------------------+----------------------------------
Comment (by Juan Navarro):
Bug reporter here. I'd just want to mention that for the internal project
that needed it, I've been successfully using the patched branch provided
in comment:4, without issues, for the last 2 years.
My real-world use case has been a program that records incoming RTP, with
a command that looks like this:
{{{
ffmpeg \
-protocol_whitelist file,rtp,udp \
-fflags +discardcorrupt+genpts \
-use_wallclock_as_timestamps 1 \
-i input.sdp \
-map 0:a:0 -c:a copy \
-map 0:v:0 -c:v copy \
-f webm -flags +global_header \
-y recording.webm
}}}
So I'd like to endorse the changes proposed in the mentioned branch.
The issue seemed to be, from what I understood in the patchwork
conversation (comment:8), that the current code design of FFmpeg around
signal handling does make a difference between handling signals for the
main loop, and handling them within nested loops (and that's where the
need for ''two'' signals came from, and the motivation for this report)
I'd agree that the user experience of requiring two signals is already
strange, but requiring them ''only some times'', makes it even more
confusing. IMO it's all due to an internal implementation detail, which
should not leak to the user.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9009#comment:13>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".
