Current tested features (note, some of these are not exposed in the
driver except by changing the source code):
- * HDMI and SDI capture on 576p60, 720p60, 1080i60 (1080p60 is unfortunately
- not supported in newer firmwares; I haven't tried older), plus 24, 50
- and 59.97 Hz
- * 8-channel 24-bit 48 kHz locked audio capture
- * Analog audio capture, including setting levels
- * 8-bit 4:2:2 and 10-bit 4:2:2 capture
+ * HDMI and SDI capture on a variety of modes including 720p60, 1080p30 and
+ 1080i60. 1080p60 is unfortunately not supported, despite earlier (now
+ retracted) promises by Blackmagic that it would come in a future firmware
+ revision (this is unlike the Thunderbolt versions, where some older firmware
+ revisions _do_ support it).
+ * 8-channel 24-bit 48 kHz locked audio capture.
+ * Analog audio capture, including setting levels.
+ * 8-bit 4:2:2 and 10-bit 4:2:2 capture.
The BlackMagic cards follow a protocol whose exact format is still
-unknown, and the driver is still in alpha stage. (There is no API or
-ABI stability, for one, and everything is really messy and uncommented.)
-In particular, it will often do something on init that makes the card
-seemingly reset and disconnect off the bus (and then reset).
-This being said, once it's actually up, I've done ten-hour 720p60
-captures on my Lenovo X240 without a single drop.
+unknown, and the driver is still in beta stage. (The API/ABI is nearing
+stability, but is still not really locked.)
It seems to want about 10–15% of one CPU core; a significant chunk of this is
-copying data from the kernel over to userspace. However, it supports custom
-memory allocators, so that once the USB packets are in userspace, you can
-decode directly into e.g. pinned GPU memory.
+copying data from the kernel over to userspace, which can be skipped by means
+of zerocopy USB if you have a very recent libusb (>= 1.0.21) and a recent
+kernel (>= 4.6.0). There's a decode step which also takes some time and memory
+bandwidth, but it supports custom memory allocators, so that once the USB
+packets are available to userspace, you can decode directly into e.g. pinned
+GPU memory.
The driver itself lives in bmusb.cpp; main.cpp contains a very simple
client that just checks for frame continuity. It's recommended to run
as root or some other user that can run the USB thread at realtime
priority, as USB3 isochronous transfers are very timing sensitive.
-The driver has only been tested with the firmware from the 10.4.3/10.5.0
-series (seemingly the same), and there is currently no tool to
-upgrade or downgrade the firmware on the card.
+The driver has been tested with various firmware versions; they seem to
+behave mostly the same. There is currently no tool to upgrade or downgrade
+the firmware on the card.
bmusb is Copyright 2015 Steinar H. Gunderson <steinar+bmusb@gunderson.no>
and licensed under the GNU General Public License, version 2, or at your
projects / bmusb / commitdiff