Frequent crashing in our production. Advice needed

[nicwillu]

Hi there! We've recently switched from Tricaster to purely OBS and streamdecks for our shows. Recently, OBS will just crash out of the blue during the production. We record and stream. It seems to be GPU related but I just cannot really narrow it down to what the problem actually is. Would anybody have any idea?

I assume we could try using just x264 encoding instead of Nvidias encoder to see if that does anything. But if anyobdy can tell from the reports what the problem might be, that would be super helpful.

Log: https://obsproject.com/logs/FQFw4Ea8EsUB1wqu
Crash log: https://obsproject.com/logs/EvdkrtPe0DjXB0Ro

 

[koala]

It crashes in the NDI plugin while using NDI as output. Make sure you're using the latest NDI plugin as well as the NDI library.

 

[nicwillu]

It crashes in the NDI plugin while using NDI as output. Make sure you're using the latest NDI plugin as well as the NDI library.

Hmm. We rely heavily on NDI. We are running version 5.0.5.0 (which is the latest from ndi tools website) and the latest NDI OBS plugin. Would that mean this is not resolvable and that we might have to cut some slack on our NDI usage? Any troubleshooting possible?

Also, could you tell me how you could see NDI was at fault? That way I can understands the logs better next time.

 

[nicwillu]

I suspect it might be the hardware? I run NDI in a much larger scale on other productions and it works flawlessly, using different computers and laptops to output NDI all over the place. While the only output we are doing at this production is sending a playback timer to another screen..

 

[koala]

Look into the crash log and locate the 1st thread section, the one that is marked as "(Crashed)":

Thread 13C8: libobs: graphics thread (Crashed)
Stack            EIP              Arg0             Arg1             Arg2             Arg3             Address
000000FE83BFF9D0 00007FFE852A2F57 000002A427699B01 0000000000000001 000002A427699BC0 0000000000000000 w32-pthreads.dll!pthread_mutex_unlock+0x27
000000FE83BFFA30 00007FFE70D8D266 0000000000000000 000002A4D51738A0 0000000000000438 000002A57136C3C0 obs.dll!video_output_lock_frame+0x106
000000FE83BFFA60 00007FFE70B16A0B 000002A42736E8E8 0000000000000001 0000000000000010 0000000000000000 obs-ndi.dll!ndi_filter_offscreen_render+0x1cb
000000FE83BFFB70 00007FFE70DE2ECF 0000000000000001 000000FE83BFFCC0 000002A42736E8E8 0000000000000001 obs.dll!render_video+0xcf
000000FE83BFFBC0 00007FFE70DE24F0 0000000000000002 0000000000000002 0000000000000001 0000000000000000 obs.dll!output_frame+0xa0
000000FE83BFFD00 00007FFE70DE22B0 000002A57178A600 0000000000000000 0000000000000000 0000000000000000 obs.dll!obs_graphics_thread_loop+0x170
000000FE83BFFD90 00007FFE70DE210D 000002A47B2AF8D0 000002A47B2AF8D0 0000000000000000 00007FFE89863A81 obs.dll!obs_graphics_thread+0x12d
000000FE83BFFE50 00007FFE852A5924 000002A573C47870 0000000000000000 0000000000000000 0000000000000000 w32-pthreads.dll!ptw32_threadStart+0x74
000000FE83BFFED0 00007FFE89871BB2 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ucrtbase.dll!0x7ffe89871bb2
000000FE83BFFF00 00007FFE8B027034 0000000000000000 0000000000000000 0000000000000000 0000000000000000 kernel32.dll!0x7ffe8b027034
000000FE83BFFF30 00007FFE8C102651 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x7ffe8c102651

Ignore the hex digits and look at the rightmost column. Look from top to bottom until you find some OBS-specific module. This is either an internal OBS DLL or some plugin DLL, and in your case it's obs-ndi.dll that executed some function ndi_filter_offscreen_render, and slightly below there was a function output_frame, which leads me to the conclusion the crash happened in the ndi plugin while outputting some frame.

If you use NDI and your setup (including the networking part) is ok, I assume the only thing you can do is contacting the ndi plugin author and tell about that crash. If it is some issue with hardware, I cannot tell. May be it's some network issue that leads to stalling of the data on the network, and the plugin isn't able to handle this gracefully.

In your regular log, I see you switch between color space NV12 and RGB - RGB is kind of unusual, and hardware/shader support isn't available for handling this, so using RGB might also affect the stability of NDI. But this is just a wild guess. You will get the most stability with NV12 I assume, since this is the standard and most often used (thus most issues removed).