GNOME Bugzilla – Bug 747633
decklinkvideosrc: crash in ::VideoInputFrameArrived() callback with video_frame=NULL
Last modified: 2016-05-05 07:08:55 UTC
Using the following pipleline gives me a segmentation fault when I attempt to capture audio and video from a Blackmagic Intensity Pro card, using the latest git master: gst-launch-1.0 decklinkvideosrc mode=18 connection=2 buffer-size=60 ! videoconvert ! theoraenc ! queue ! m. decklinkaudiosrc connection=1 ! audioconvert ! vorbisenc ! queue ! m. oggmux name=m ! filesink location='blah.ogg' The segfault looks like: Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstDecklinkInputClock Redistribute latency... Caught SIGSEGV
+ Trace 234956
Thread 2 (Thread 0x7f0c7f4fb700 (LWP 13576))
I'm happy to help debug, try patches, etc.
We could just ignore NULL frames, but why would we get NULL frames at all? Also we can't really do anything with the audio in those cases either, because we need to get the hardware reference clock time at the time of capture... which we can only get from the video frame, not the audio packet. Maybe we could send the audio with GST_CLOCK_TIME_NONE and then interpolate. If you just ignore the audio when a NULL video frame is arrived, do you get dropouts in the audio?
Jared, did you make any progress debugging this?
Jared, have you had a chance to debug this some more? Do you need any help from us with debugging this some more? What we're interested in is basically what happens with the audio if there are NULL frames (which are kind of unexpected in the first place).
Created attachment 308941 [details] [review] decklinkvideosrc: don't crash if we get NULL video frames in the callback Should just check for NULL video_frame and audio_packet, even if we don't understand why we get those in the first place.
Created attachment 325380 [details] [review] 0001-decklinkaudiosrc-Don-t-crash-when-receiving-video-fr.patch There's the same problem with audio, but there we can properly fix it as we know the video frame and thus the capture time.
Comment on attachment 308941 [details] [review] decklinkvideosrc: don't crash if we get NULL video frames in the callback This should work fine as we will just assume continuous audio if we pass no timestamp. It just must not happen for the very first frame. We should just throw away the audio in that case inside decklinkaudiosrc (if we got no timestamp and the time tracking is not initialized yet).
commit f06647fd0ce6ae1682426c446f9066ecdf942045 Author: Sebastian Dröge <sebastian@centricular.com> Date: Tue Apr 5 14:49:51 2016 +0300 decklinkaudiosrc: Don't accept packets without timestamps after a discont We have no idea which timestamps they are supposed to have so the only thing we can do at this point is to drop them. Packets without timestamps happen if audio was captured but no corresponding video, which shouldn't happen under normal circumstances. https://bugzilla.gnome.org/show_bug.cgi?id=747633 commit 0004920c83835fcd5c54ed1197d03d3d8117c44e Author: Sebastian Dröge <sebastian@centricular.com> Date: Mon Apr 4 22:21:30 2016 +0300 decklinkaudiosrc: Don't crash when receiving video frames but no audio And mark these events as disconts to reset time tracking in the audio source. https://bugzilla.gnome.org/show_bug.cgi?id=747633 commit 8abff20185211756e1a87f553c31a471b9c9744e Author: Tim-Philipp Müller <tim@centricular.com> Date: Sat Aug 8 15:17:54 2015 +0100 decklinkvideosrc: don't crash if we get NULL video frames in the callback For some reason we seem to sometimes get NULL video_frames in the ::VideoInputFrameArrived() callback, observed on Intensity Pro cards. https://bugzilla.gnome.org/show_bug.cgi?id=747633
*** Bug 766015 has been marked as a duplicate of this bug. ***