Segfault on simple NDIlib send program

dhopson

New member
So we're trying to integrate NDI as one of the supported outputs in our video rendering system, written in Rust.

I'm hitting a segfault with no obvious explanation, and I'm seeing some issues online complaining of a similar issue with no identified cause in C++ and C#.

Anyone else hitting this? Any ideas what's causing it?
I've confirmed with automated tests that my hand-written wrapper types for Rust have the correct ABI, calling convention, alignment, size, layout, etc, so I doubt that's the issue.
The platform I'm hitting the issue on is x64 Windows 10 build 1909.

I can provide a little sample code for you of how we're configuring NDIlib's senders, but the application is rather simple.
We're using UYVY for the pixel format, as that was supported by the NDI SDK and it's also what our video system uses internally for processing.

The issue happens as soon as NDIlib_send_send_video_v2() is called with the first batch of frame data.
Code:
fn SendVideoFrame(&self, FrameSize : &Size2D, FrameData : &[u8]) -> Result<(), String>
    {
        static UYVY_FourCC : NDIlib_fourcc = NDIlib_fourcc::New(b"UYVY");

        let FrameStruct =    NDIlib_video_frame_v2_t
                            {
                                timecode : i64::MAX, //Tell NDIlib to create a timecode for us. This is how it's defined in their C header.
                                xres : FrameSize.Width as c_int,
                                yres : FrameSize.Height as c_int,
                                fourcc : UYVY_FourCC,
                                p_data : FrameData.as_ptr(),
                                data_size_or_line_stride : FrameData.len() as c_int,
                                frame_format_type : NDIlib_frame_format_type_e::NDIlib_frame_format_type_progressive,
                                .. NDIlib_video_frame_v2_t::default()
                            };

        unsafe { NDIlib_send_send_video_v2(self.Internal, &FrameStruct); }

        Ok(())
    }

Here's a backtrace I get in gdb:
Code:
(gdb) bt
#0  0x00007ffce8e2bd1a in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#1  0x00007ffce8e2f005 in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#2  0x00007ffce8e70f73 in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#3  0x00007ffce85f55bc in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#4  0x00007ffce82fb099 in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#5  0x00007ffce82f8b24 in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#6  0x00007ffce82fad2b in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#7  0x00007ffce82f8428 in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#8  0x00007ffce82cbb37 in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#9  0x00007ffce82cc5b4 in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#10 0x00007ffce82cb396 in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#11 0x00007ffce82d3fb8 in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#12 0x00007ffce82cc507 in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#13 0x00007ffce82c5b85 in Processing.NDI.Lib.x64!NDIlib_util_P216_to_V210 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#14 0x00007ffce8289e66 in Processing.NDI.Lib.x64!NDIlib_routing_get_source_name () from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#15 0x00007ffce828a889 in Processing.NDI.Lib.x64!NDIlib_send_send_video_v2 ()
   from C:\msys64\mingw64\bin\Processing.NDI.Lib.x64.dll
#16 0x00007ff7762cb4a7 in projector::rendering::sinks::ndi::NDISession::SendVideoFrame ()
    at Z:\coyoterepos\coyote-player\projector\src\rendering\sinks\ndi/mod.rs:74
#17 projector::rendering::sinks::ndi::NDIVideoSplitter::OnSinkSample ()
    at Z:\coyoterepos\coyote-player\projector\src\rendering\sinks\ndi/mod.rs:294
#18 0x00007ff7762c602c in projector::rendering::sinks::ndi::{{impl}}::Init::{{closure}} ()
    at Z:\coyoterepos\coyote-player\projector\src\rendering\sinks\ndi/mod.rs:272
#19 0x00007ff7762f0050 in alloc::boxed::{{impl}}::call_mut<(&gstreamer_app::auto::app_sink::AppSink),FnMut<(&gstreamer_app::auto::app_sink::AppSink)>,alloc::alloc::Global> ()
    at C:\Users\Admin\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib/rustlib/src/rust\library\alloc\src/boxed.rs:1553
#20 gstreamer_app::app_sink::trampoline_new_sample::{{closure}} ()
    at C:\Users\Admin\.cargo\registry\src\github.com-1ecc6299db9ec823\gstreamer-app-0.16.5\src/app_sink.rs:231
#21 core::ops::function::FnOnce::call_once<closure-0,()> ()
    at C:\Users\Admin\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib/rustlib/src/rust\library\core\src\ops/function.rs:227
#22 std::panic::{{impl}}::call_once<gstreamer::auto::enums::FlowReturn,closure-0> ()
    at C:\Users\Admin\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib/rustlib/src/rust\library\std\src/panic.rs:344
#23 std::panicking::try::do_call<std::panic::AssertUnwindSafe<closure-0>,gstreamer::auto::enums::FlowReturn> ()
    at C:\Users\Admin\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib/rustlib/src/rust\library\std\src/panicking.rs:379
#24 std::panicking::try<gstreamer::auto::enums::FlowReturn,std::panic::AssertUnwindSafe<closure-0>> ()
    at C:\Users\Admin\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib/rustlib/src/rust\library\std\src/panicking.rs:343
#25 std::panic::catch_unwind<std::panic::AssertUnwindSafe<closure-0>,gstreamer::auto::enums::FlowReturn> ()
    at C:\Users\Admin\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib/rustlib/src/rust\library\std\src/panic.rs:431
#26 gstreamer_app::app_sink::trampoline_new_sample ()
    at C:\Users\Admin\.cargo\registry\src\github.com-1ecc6299db9ec823\gstreamer-app-0.16.5\src/app_sink.rs:230
#27 0x00007ffd1dbb72a6 in ?? () from C:\msys64\mingw64\bin\libgstapp-1.0-0.dll
#28 0x00007ffd164208af in ?? ()
   from C:\msys64\mingw64\bin\libgstbase-1.0-0.dll
#29 0x00007ffd164224cd in ?? ()
   from C:\msys64\mingw64\bin\libgstbase-1.0-0.dll
#30 0x00007ffd033f8264 in ?? ()
   from C:\msys64\mingw64\bin\libgstreamer-1.0-0.dll
#31 0x00007ffd033fa6e9 in ?? ()
   from C:\msys64\mingw64\bin\libgstreamer-1.0-0.dll
#32 0x00007ffd03402039 in ?? ()
   from C:\msys64\mingw64\bin\libgstreamer-1.0-0.dll
#33 0x00007ffd1642d22c in ?? ()
   from C:\msys64\mingw64\bin\libgstbase-1.0-0.dll
#34 0x00007ffd033f8264 in ?? ()
   from C:\msys64\mingw64\bin\libgstreamer-1.0-0.dll
#35 0x00007ffd033fa6e9 in ?? ()
   from C:\msys64\mingw64\bin\libgstreamer-1.0-0.dll
#36 0x00007ffd03402039 in ?? ()
   from C:\msys64\mingw64\bin\libgstreamer-1.0-0.dll
#37 0x00007ffd163ab8f6 in ?? ()
   from C:\msys64\mingw64\lib\gstreamer-1.0\libgstcoreelements.dll
#38 0x00007ffd03431cec in ?? ()
   from C:\msys64\mingw64\bin\libgstreamer-1.0-0.dll
#39 0x00007ffd18698d5f in ?? () from C:\msys64\mingw64\bin\libglib-2.0-0.dll
#40 0x00007ffd18698361 in ?? () from C:\msys64\mingw64\bin\libglib-2.0-0.dll
#41 0x00007ffd25464f33 in ?? () from C:\msys64\mingw64\bin\libwinpthread-1.dll
#42 0x00007ffd31a4b04a in msvcrt!_beginthreadex ()
   from C:\WINDOWS\System32\msvcrt.dll
#43 0x00007ffd31a4b11c in msvcrt!_endthreadex ()
   from C:\WINDOWS\System32\msvcrt.dll
#44 0x00007ffd31917c24 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\System32\kernel32.dll
#45 0x00007ffd32d0d721 in ntdll!RtlUserThreadStart ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#46 0x0000000000000000 in ?? ()

It seems to be choking on a (possibly recursive?) call to NDIlib_util_P216_to_V210().

Any help that can be offered is appreciated.
 

Jarno

Post-LW Engineer
The data_size_or_line_stride should be the line stride for UYVY formats, not the total data size.

---JvdL---
 

dhopson

New member
The data_size_or_line_stride should be the line stride for UYVY formats, not the total data size.

---JvdL---
Thank you, I figured that out earlier today. A bit odd that it computes the buffer length itself rather than using the length for a sanity check. Oh well.
 
Top Bottom