AJA capture/playout plugin: Move it upstream or not?

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.

Let me know your opinions and questions! :slight_smile:

1 Like

Your code looks definitely leaner and more appropriate.

I also thinks it fine if it doesn’t build if you don’t have the sdk, I don’t see this being part of our binaries anyway :grin:

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’d love to see it upstreamed (your newer version)

The unknown as @ndufresne says is getting the SDK into the CI system.

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.

1 Like

the version on github is slightly different to that from the developer program - just FYI

1 Like

The merge request for this can be found at Merge AJA audio/video source/sink plugin (!5523) · Merge requests · GStreamer / gstreamer · GitLab

I’ve also changed the version on GitHub to include a meson subproject for building the AJA NTV2 SDK from GitHub btw.