After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 747633 - decklinkvideosrc: crash in ::VideoInputFrameArrived() callback with video_frame=NULL
decklinkvideosrc: crash in ::VideoInputFrameArrived() callback with video_fra...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal critical
: 1.8.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
1.6.4
: 766015 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-04-10 15:15 UTC by Jared Smith
Modified: 2016-05-05 07:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
decklinkvideosrc: don't crash if we get NULL video frames in the callback (1.25 KB, patch)
2015-08-08 14:21 UTC, Tim-Philipp Müller
committed Details | Review
0001-decklinkaudiosrc-Don-t-crash-when-receiving-video-fr.patch (4.57 KB, patch)
2016-04-04 19:23 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Jared Smith 2015-04-10 15:15:24 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

Thread 2 (Thread 0x7f0c7f4fb700 (LWP 13576))

  • #0 nanosleep
  • #1 g_usleep
  • #2 fault_handler_sighandler
    at gst-launch.c line 112
  • #3 fault_handler_sighandler
    at gst-launch.c line 93
  • #4 <signal handler called>
  • #5 GStreamerDecklinkInputCallback::VideoInputFrameArrived(IDeckLinkVideoInputFrame*, IDeckLinkAudioInputPacket*)
    at gstdecklink.cpp line 489
  • #6 CDeckLinkInput::inputFrameArrivalCallack()
  • #7 CDeckLink::DriverNotificationThreadFunction(void*)
  • #8 start_thread
  • #9 clone

I'm happy to help debug, try patches, etc.
Comment 1 Sebastian Dröge (slomo) 2015-04-11 17:29:06 UTC
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?
Comment 2 Sebastian Dröge (slomo) 2015-06-07 18:19:43 UTC
Jared, did you make any progress debugging this?
Comment 3 Tim-Philipp Müller 2015-08-08 14:08:02 UTC
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).
Comment 4 Tim-Philipp Müller 2015-08-08 14:21:20 UTC
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.
Comment 5 Sebastian Dröge (slomo) 2016-04-04 19:23:12 UTC
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 6 Sebastian Dröge (slomo) 2016-04-04 19:24:53 UTC
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).
Comment 7 Sebastian Dröge (slomo) 2016-04-05 11:51:22 UTC
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
Comment 8 Sebastian Dröge (slomo) 2016-05-05 07:08:55 UTC
*** Bug 766015 has been marked as a duplicate of this bug. ***