Currently there’s an AJA (SDI/etc) capture/playout plugin available from here, in addition to one written by AJA themselves here.
I’ve contributed to the one from AJA for a long time but then decided to write a new one to simplify the whole thing considerably. That’s why there are two now.
As the plugin is stable and used in production since a long time now, I was wondering whether we should move this plugin upstream into gst-plugins-bad. There are however two questions that have to be discussed first
There are two plugins. Is everybody OK with using the “new” one that I wrote instead of using the one that is maintained (not very actively) by AJA themselves?
Building the plugin requires the proprietary AJA SDK. Getting this SDK requires to sign up for their developer program, which is free and you’d probably do anyway if you build a product around AJA hardware (so you can actually get access to their technical documentation, etc). It’s not an option to replicate the headers of the SDK and dlopen it, like we do e.g. for NVIDIA, as this is a quite large C++ SDK.
I think the first part of your request is clear, it can be upstreamed. But I think include it in our CI seems like a greater challenge since the SDK would have to be added to public runner images which will likely be inviolation of the SDK license. The issue with no CI is if maintenance stops though.
I don’t we can realistically include the SDK in the CI as that effectively makes it available to everybody and we can’t legally redistribute it.
Not including the build of it in the CI is indeed a problem I didn’t consider though, thanks! The question then is if we want to block on that or not. There are also other plugins that we don’t build on the CI yet.
It could be nice to actually closely track them somewhere, but yes, specially ARM BSP features. What I tried to say is that if there is enough users for such thing, I’d be fine.
Another thing to ask is how LGPL is that? It seems rather borderline when using closed source headers, so maybe the plugin code itself will have to be made BSD, with the plugin must be marked proprietary?
I think that depends on whether you consider this a system library or not, which is AFAIU not a very well defined term so there’s some ambiguity there in the license.
FWIW, the SDK itself is MIT licensed. Just when signing up to their developer program you have to agree to some more things…
Also I just noticed, since a year there is an open source version of the SDK available on AJA’s GitHub. So this part of the discussion is actually solved, I just didn’t notice. Sorry for that!
I’ll create an MR for integrating the plugin into gst-plugins-bad and for building the SDK from GitHub as part of it for the CI. I actually even have a meson.build for the SDK so could make it a proper meson subproject.
Hi All- My apologies for being a bit late to this party. I’m the engineering manager for the AJA desktop I/O products (which the ntv2 library controls). We do indeed have a fully open source (MIT) library and Linux driver (our windows and mac drivers are not open source, but work w/ the open source library). Some things mentioned in this discussion I thought I might clarify, we do still have our NDA required developer program (which is free and open to OEMs) but membership in this program is not required to use and distribute the Linux driver and SDK as both are open source.
Also, the current link to the SDK is here: GitHub - aja-video/libajantv2: Open-source library for AJA Video Systems desktop IO cards. I apologize for the confusion, however the repo used currently by this is our deprecated one. We still have it available for projects that want to use it, but we’ve since moved to the new repo above as it’s a direct mirror of the repo we use internally (unlike the previous repo which was a squashed and reorganized version of the repo we were using at that time).
Please feel free to reach out if there’s anything we can help with. We’re currently helping maintain the OBS plugin, but are happy to help out however we can.
We already have an issue open for moving to the new repository. It’s on my list but I didn’t get to it yet. The bump in major version number also feels like there might be some API changes that need to be taken care of but I didn’t look into that yet.
Sounds good. Please let me know if we can be of any assistance in getting things moved. There are some significant changes w/ the Kona XM hardware, as there are firmware configurations that support streaming DMA (instead of the traditional frame based DMA). Although we’re still in early days on that feature, and it’s currently only supported in the Kona X/XM hardware.
