Adding Black Magic Design Decklink support to FFMPEG Preset #543
Conversation
This commit adds support for windows-x86_64, but plan to add support for all platforms.
Also need to install this for widl.
pacman -S mingw-w64-{i686,x86_64}-tools-git
|
This links against a dynamic library we can't bundle, am I correct? |
|
Shouldn't be. Which library are you referring to? The only thing it should be linked to are native libraries. Here is the one I built yesterday before the pull request.
|
|
Ok, looks good. Please add the installation of the SDK in the |
|
Yeah, I'm going to have to make some changes to make this work. There is no way to download the SDK automatically that I can see (used to be available). And even if we could, their license for the SDK as a whole is different than the license for the individual files (which is more permissive). Next best option is to simply copy the appropriate header files directly into the repo. When a new update occurs, simply download the new SDK and install the appropriate headers again. Annoying, but doable. Zeronae used to support it but removed said support, claiming incompatible license. I cannot find any section in either of the license agreements that would cause a conflict with an existing license we have, and as you have seen, we don't like to any binaries. So I'm going to proceed forth with the intent of adding decklink support. I'll ping when I'm done. |
|
If FFmpeg just needs a few small header files, we can just add them to this repository in |
|
The following platforms should now support decklink via FFMPEG: Verified the Windows build with my local machine. Will test against an actual decklink in the coming week. |
|
Wow, that's a lot of header files, let's put that somewhere else... |
|
No problem. Will make a separate repo here on github. Gonna be a couple of days before I get to it, potentially. |
|
It looks like we can download from their site without registering though. Let's do that? |
|
That's for the drivers. We need the SDK. Or did you find a different link? |
|
I see. These files already appear to be available in other repositories though, for example: |
|
Looking into this. |
I can now detect when a source is not available using the flags field of the AVPacket.
|
Finally got an answer back. The EULA for the SDK is designed so that a single public point is available for downloading the SDK. This does in fact prevent us from using their headers, since the GPL requires that we provide all sources (including the decklink headers) to anyone we distribute our libraries to. If possible, I would like to revert back to my previous implementation which will detect the SDK on the machine where the build is happening. Since we won't have the SDK installed on the CI servers, it won't add decklink to your normal distribution. Then I can make local builds of FFmpeg with decklink support without the need to maintain a separate branch. Seem reasonable? |
|
We don't need to redistribute it under GPL, but it can't be redistributed
at all. So I guess we'd have to do like with FlyCapture and try to make the
SDK only accessible to the CI servers. If you're satisfied with local
builds for now though, that's fine, yes.
|
Added a patch to remove references to unredistributable files from within the FFmpeg source code.
Added a patch to remove references to unredistributable files from within the FFmpeg source code.
|
For now though, please remove from this PR the files from the SDK so we can merge this! Thanks |
|
I should be able to finish this by the weekend. |
|
This adds support for windows 32 and 64. I've only tested the 64-bit version, but it works. Added some patches to ignore SDK files; this keeps our license kosher. There is also a patch to the FFmpeg decklink code so that I can tell if a video source stops producing frames. Let me know if you need anything else. |
|
Looking good, but DeckLinkAPI.h and DeckLinkAPI_i.c are still there, could you remove them? Let's also remove LICENSE.DeckLinkAPI since it is misleading. Could we also consolidate all the patches into one big decklink.patch? Thanks! |
|
Are you saying that DeckLinkAPI.h and DeckLinkAPI_i.c are not part of the SDK? Sounds like they were generated from the SDK... And what's with the DeckLinkAPI.LICENSE file? |
|
They are indeed generated from the SDK. I believe that allows them to fall under the permissive license (which I included). Would you prefer them elsewhere? I guess we could generate them, but you'd have to install the SDK on the server, along with some additional msys libs. I will take care of the patches. |
|
Right, so maybe it's alright. Is this what your contact at DeckLink said? |
|
That is correct; the files in the SDK cannot be distributed, but files generated from the SDK can be distributed under the permissive license. |
|
Is this in the license that came with the SDK you have?
It sounds like we would still need their permission. Can you forward me the message you got from DeckLink about this? |
|
That is not the correct license. You can read the full license by attempting to download the SDK (copy it into notepad). Derivative works are not mentioned. Permitted Use:
|
|
Builds look like they have the appropriate stuff. Do you want to wait for BMD to look at this, or just go for it? Based on their comments, as long as we include the license like we have, we should be good. |
|
@masterav10 Yeah, if we could have them look at this PR just to make sure that would be great. Otherwise looks good, though does this not build on Linux or Mac? We'd need something more for that? |
|
Any news from them? Have the OKed this PR? |
|
No word yet. I could try to send another email. |
This pull request enables decklink device support if the appropriate Black Magic SDK is installed on the build machine.
Currently enabled for only Windows x86_64. The SDK supports windows, linux, and mac, so we can probably add decklink to those platforms as well.
I have verified that the devices are enumerated through libavdevice on a machine with a Black Magic Decklink Quad. Haven't had a chance to hook up to the them, though.
In addition to this pull request, we need to do the following:
pacman -S mingw-w64-{i686,x86_64}-tools-git dos2unixIf we don't want the backoff approach as taken here, we could include the headers directly into the repository under src/main/resources. Then we don't have to the above. However, it places more burden on the maintainer, since you have to download the SDK and run midl to get the appropriate headers. Let me know if you'd rather change to this approach.