Real-time video processing on Jetson TK1

Hey, I’m interested in the Jetson TK1. But before buying one I’d like to check whether what I want to do is actually possible.

I would like to use the Jetson for real-time video processing. In my setup there is a signal coming in from another device over HDMI; the Jetson does some visual processing on this; then outputs it again to be displayed on a screen.
I’d like to work in 1080p 60fps.

The Jetson doesn’t have a HDMI input, so I thought of equipping it with the Blackmagic DeckLink Mini Recorder, a PCIe capture card. This should be possible with a passive adapter (right?).

Has the DeckLink Mini Recorder ever been tested with the Jetson?
Does this setup sound feasible?


I didn’t see any models designed for the “mini” PCIe slot. I saw there are models that use PCIe x1, which is what the mPCIe slot is. I did notice that there was mention of a linux driver, but I didn’t see any details…if that driver exists for the kernel version used in Jetson, and if there is a mini-PCIe x1 version it would probably work. That’s a lot of if. It seems plausible that a mPCIe version stands a chance of working…find out if there is a mPCIe version and then find out what kind of driver is used.

Yeah, I was interested in the model with the PCIe x1 connector.
They don’t have anything with mPCIe since they aim at desktop computers.

They offer their own Linux drivers and an SDK. In the system requirements they mention:

Basic system requirements:

  • 32 bit x86 running Linux 2.6.18 or higher
  • 64 bit x86_64 running Linux 2.6.18 or higher
    A 64 bit kernel and ample memory is strongly recommended.

They support Ubuntu 10.04 - 14.04.

They don’t mention ARM. Would these drivers work on Linux for Tegra?
I’ve asked their support if they have any experience with ARM based systems.

If the driver is available in source code you can try to compile it against Jetson’s kernel, which is certainly newer than the required 2.6.18. There may be issues if the driver was never intended to work with something as new as a 3.x version. It is even possible that the driver is part of the default distributed kernel source, in which case you don’t even need to worry about whether it will work with 3.x…I’d find out the name of the driver and if the driver is or is not part of the 3.x series, or whether it is only available when downloaded from the manufacturer and manually added to kernel source for compile (or worse, if it is only in binary form).

Once you know the driver works with 3.x series kernels, there is a last issue which might be a problem. Various CPUs offer different extensions, and if something x86 such as SIMD extensions not available on ARM are used, then it isn’t just a matter of compiling the driver under an ARM compiler…the given extensions would have to be rewritten generically or using alternate ARM extensions (e.g., NEON, which isn’t available to x86…and video is one of those applications often using extensions due to needed speed).

Keep in mind that you don’t need to have an actual Jetson to download it’s kernel source and explore the available drivers. If the drivers are not available, you can still try to add downloaded kernel driver source to the kernel and cross compile it without an actual Jetson.

You’ll still be left with the issue of converting PCIe x1 to mPCIe. Having PCIe run at full speed is actually somewhat picky versus data lane signal quality, and having PCIe automatically back off to a slower value (due to signal quality) might matter on full speed video capture bandwidth. Having an adapter between the mPCIe slot and the PCIe x1 full-sized connector can easily cut signal quality enough that only the slowest revision of x1 speeds will ever be reached. In short, any kind of adapter risks forcing data transfer to cut down to revision 1 speeds, but revision 2 might be needed for “burp free” video capture. PCIe revision 1 speeds are easy to reach; signal quality requirement for rev. 2 goes up a lot; reaching a rev. 3 speed requires a very high quality signal a slot adapter could destroy.

Thanks for the explanation linuxdev, very helpful.
I tried to investigate the source code and search for the driver but I got lost pretty much immediately… so that didn’t work out for me ^^"

I did get a response from Blackmagic today saying that ARM and embedded platforms are not supported:

That in combination with PCIe x1 being tedious rules out the Blackmagic for me.

In the meantime I did discover an interesting alternative though: the Magewell XI100DME-HDMI.

This is a mini PCIe card (so it will stick out) that officially supports Linux 2.6.38 and above.
It is brand new so not a lot of reviews yet, but the reviews of their USB dongle are all positive. Especially about their devices being plug and play because they use standard drivers.
It uses SG-DMA for data transmission, so it will (apparently) use less resources than a similar USB device.

Everything looks alright, so I’ll probably go for this one.

For the mPCIe I don’t see a picture of the bottom of the Magewell board. The reason I wonder about this is that although the mounting standoffs on Jetson do not need to be used, they are metal and you wouldn’t want the bottom of the board to short exposed traces there (some mPCIe full length cards leave a blank pad at the half length mount points).

I have mounted mPCIe full length cards before in half length slots using nothing more than nylon fishing line, but these were all “rev. 1” speed cards. Less than perfect mounting of a “rev. 2” speed capable mPCIe card could result in it dropping back to “rev. 1” speeds. “rev. 1” speeds are quite easy to achieve and mounting is not much of a concern there.

If the full-sized USB is set for USB3 it tends to work quite well. YMMV, but for this kind of use you would probably want to disable sleep mode for USB. This seems to be a likely solution for what you are doing, but you won’t really know until you try the actual hardware on the Jetson. You might want to find out which kernel features need to be enabled for this USB dongle just to make sure the Jetson’s kernel is new enough for this without back-porting; obviously the USB config itself is fine, but specific features to this dongle may have to be enabled on an embedded system even if desktop systems tend to enable it by default.

Can’t find any pictures of the bottom side. They might start popping up this week once the shops receive them.
Isn’t it possible to simply shield this with some tape? Or would this be unreliable?

Are this devices really that sensitive to bad connections? I imagine the connector should fit fine but that the physical card isn’t fastened securely. Shouldn’t this be okay-ish as long as you take care?

Magewell also offers a dongle with USB 3.0. This would be more reliable physically, but it would cause overhead which I would like to avoid.

This is possible, but depending on how the PCB is built it might have sharp spots from through-hole wire being cut; if smooth, it won’t matter, if sharp, you’d need to be careful of insulating material. A low dielectric material would be advised.

There can be a big difference on various PCIe cards on how well error detection and error correction are handled. I’ve found this particular mPCIe slot is somewhat sensitive to cheaper mPCIe cards. I’ve seen several rev. 2 capable cards revert back to rev. 1 speeds on Jetson. A lot goes into a correctly working signal for each lane of PCIe, and once you get to rev. 2 speeds or above things get much pickier; I’ve not noticed desktop PCs as sensitive to rev. 2 speeds with their full-sized slots, but the mPCIe on Jetson is definitely sensitive to signal quality.

Whether or not the method of handling half-length mounting points on a full-length card would change things depends on how the PCB is wired and how advanced the error correction circuitry is. You’d basically just have to test and find out.

Sent a message to Magewell. They tested the mPCIe card with a Jetson and the chipset is not compatible.

Hi all,

I’ve learned a lot from the discussion above -> thanks :). @Koenraad, have you pursued this project / received any updates from Magewell on this? They’ve listed their latest “Pro Capture HDMI” as supporting arm. I’m wondering if you’ve found ways around the other problems you’ve discussed above also


I’m also looking to purchase a capture card capable of streaming 1920x1080 RGB 4:4:4 60fps (or alternatively 30fps) video (uncompressed) to a Jetson for video processing so if you’ve been able to do this it would be good reference.