Blackmagic Forum

Hello,

We are seeing some issues with occasional frame data corruption (parts of previous images overlaid over the current frame).

While debugging we found that we could reliably reproduce a similar issue by having a thread unrelated to the data capturing thread run external commands through QProcess or std::system (which made us think that the issue might probably be caused by an interaction with fork-exec).

Here is a patch to get from the Capture SDK example to a minimal version that exhibits the problem:

Code: Select all

diff -upr Capture_orig/Capture.cpp Capture/Capture.cpp
--- Capture_orig/Capture.cpp   2018-05-09 13:26:46.099198138 +0200
+++ Capture/Capture.cpp   2018-05-09 12:50:09.249131744 +0200
@@ -25,6 +25,9 @@
 ** -LICENSE-END-
 */
 
+#include <atomic>
+#include <thread>
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
@@ -222,6 +225,16 @@ int main(int argc, char *argv[])
    signal(SIGTERM, sigfunc);
    signal(SIGHUP, sigfunc);
 
+  std::atomic_bool terminate{false};
+
+  auto sleeper = std::thread([&terminate]
+    {
+      while (!terminate)
+      {
+        std::system("/bin/usleep 1000");
+      }
+    });
+
    // Process the command line arguments
    if (!g_config.ParseArguments(argc, argv))
    {
@@ -392,6 +405,13 @@ int main(int argc, char *argv[])
    }
 
 bail:
+  terminate = true;
+
+  if (sleeper.joinable())
+  {
+    sleeper.join();
+  }
+
    if (g_videoOutputFile != 0)
       close(g_videoOutputFile);
 
diff -upr Capture_orig/Makefile Capture/Makefile
--- Capture_orig/Makefile   2018-05-09 13:26:46.099198138 +0200
+++ Capture/Makefile   2018-05-09 12:42:59.278492081 +0200
@@ -25,8 +25,8 @@
 #** -LICENSE-END-
 
 CC=g++
-SDK_PATH=../../include
-CFLAGS=-Wno-multichar -I $(SDK_PATH) -fno-rtti
+SDK_PATH=/usr/include/blackmagic/
+CFLAGS=-std=c++11 -Wno-multichar -I $(SDK_PATH) -fno-rtti
 LDFLAGS=-lm -ldl -lpthread
 
 Capture: Capture.cpp Config.cpp $(SDK_PATH)/DeckLinkAPIDispatch.cpp


When raw video is captured by the above version of Capture (200 frames are more than sufficient to examine the behaviour), a significant number of frames are corrupted, appearing predominantly green and overlaid with parts of previous frames. The problem becomes more apparent when the camera is in motion.

Is there any known interaction between the driver and std::system/fork-exec?
Is there a workaround or other way to mitigate this issue?

Some additional information:
Linux: openSUSE 13.2 (Harlequin) (x86_64)
Kernel: 3.16.6-2-desktop
Driver: desktopvideo-10.9.12

Best regards,
Christian Kurz

Hi Kurz,

Thanks for providing this sample. This issue has been lodged and I will update you with release plans for the fix.

Regards
Cameron

Hi Cameron,

Thank you! Please let us know if you need any additional information!

Best,
Christian

Hi Cameron,

Do you have any updates on this issue?

Best,
Christian

kurz_trackmen wrote:Hello,
Is there any known interaction between the driver and std::system/fork-exec?

In general, fork/exec in a multithreaded program is extremely hard to get right (much worse than people assume), so I'm not surprised if there are issues here. It's probably better to design your program not to require it if you can.