search

CasparCG / server

CasparCG Server is a Windows and Linux software used to play out professional graphics, audio and video to multiple outputs. It has been in 24/7 broadcast production since 2006. Ready-to-use downloads are available under the Releases tab https://casparcg.com.
GNU General Public License v3.0
914 stars 268 forks source link

iVGA input for CasparCG #379

Closed TKooijmans closed 5 years ago

TKooijmans commented 9 years ago

It would be nice to have a i-VGA input for CasperCG. Newtek has the i-VGA app free for download with makes it possible to use any PC screen in the network as video input for Tri-Caster. This works as a video and audio over IP transmitter. If this can work as input for CasperCG we do not need extra hardware for most external sources.

jamesdwise commented 7 years ago

Don't forget the Bluefish Component too.

However as the developer behind some of that code, and an employee @ Bluefish444, I can assure you that use of the code and linking to the driver is perfectly fine with Bluefish and exactly what they want.

To be honest i am still not 100% on the exact legal requirements either. Bluefish sells hardware, and the drivers are freely available via the web. Use of a Bluefish device with Caspar requires having the appropriate driver installed, but that is all. The Caspar project includes some bluefish header files, which we are totally fine for those to be re-distributed.

Anyway given the current discussion i thought i would jump in and give my 2c - especially since I (sort-of) represent one of the 3rd parties here.

** I am not a lawyer, just a programmer.

On 25/08/2017 1:47 am, Steinar H. Gunderson wrote:

We have only discussed BMD and NDI for exceptions, but perhaps Flash player should be thrown in too. How about CEF (BSD)?

The 2-clause BSD license is pretty much compatible with everything, so you don't need an exception for it.

However, if you change from GPLv3 to GPLv3 with exception clauses, you are no longer GPLv3 (nor GPLv2) compatible, and cannot link to GPL libraries unless they too include such exceptions. In particular, the FFmpeg compile CasparCG is shipping is compiled with --enable-gpl --enable-v3, and thus GPLv3, so that needs to change. Removing --enable-gpl in turn disables e.g. x264 support, since x264 is licensed under the GPL.

- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/CasparCG/Server/issues/379#issuecomment-324675374, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AWRRJg4nCC5i2aVyzKA5BFgccykpQAPjks5sbZqrgaJpZM4F_dYi.

Keksstar commented 7 years ago

Any update what happend in the background so far? Is the NDI Input still possible or has licensing to be clarified before that?

calumbrookes commented 7 years ago

+1 to this, definitely interested in helping put man-hours in towards getting NDI into Caspar if I can be of use to the project.

aircooled76 commented 7 years ago

If the use of other components are questionable as mentioned here (BlackMagic etc.) Should we work to build the code for NDI Input first and work through the licence implications after?

This would be an awesome addition to CasperCG and would enable me to expand my use of the server...

On 1 Nov. 2017 03:45, "Calum Brookes" notifications@github.com wrote:

+1 to this, definitely interested in helping put man-hours in towards getting NDI into Caspar if I can be of use to the project.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CasparCG/Server/issues/379#issuecomment-340835319, or mute the thread https://github.com/notifications/unsubscribe-auth/AFNqU5mSKaLiM65GQEfkHGDVm_2IDkI0ks5sx1W0gaJpZM4F_dYi .

calumbrookes commented 7 years ago

OK so some digging later...

This FFmpeg commit shows that FFmpeg 3.4 includes NDI support. If this is the case, then is it possible via this method to get NDI into Caspar by updating the FFmpeg libraries to 3.4 and using the FFmpeg producer and using an ndi:// URL rather than adding a separate NDI producer?

edit: interesting here in that if FFmpeg 3.4 includes the NDI libraries, does that circumvent the licensing issues by bundling them into Caspar via FFmpeg?

Palakis commented 6 years ago

@calumbrookes No it doesn't circumvent the licensing issues, because it would mean that the program relies on a proprietary component to function and the GPL tries to avoid that.

Palakis commented 6 years ago

By looking at the source of ndi ffmpeg module, it looks like it does compile-time linking to the library. IIRC doing so prevents FFmpeg from running without the NDI library installed, and thus requires bundling these with FFmpeg.

Another solution would be to use dynamic loading. NewTek provides such a mechanism in their MIT-licensed NDI headers provided in the SDK. Thus the program could work without requiring the NDI runtime/libraries and automatically enable NDI support when these become available on the system.

Julusian commented 6 years ago

I have been thinking about this problem quite a bit lately. After doing a load of research on various aspects and considering whether we could change to another license, I have a conclusion that I think is reasonable. So far I have only been thinking in terms of the NDI lib, but I expect the same can be extended to decklink and others.

First off, we have to stay with the GPL. We link against ffmpeg and x264, which is GPL, so we are required to be GPL in order to do that. Even if we were to change to LGPL or MIT, as soon as we link to ffmpeg we would be classed as GPL so nothing would have changed. We can't add any library exceptions to our GPL as doing so would also mean that we cant link against any other GPL libraries, so again would not work for us. This means we need to find a way to make this work while remaining under GPL.

The issue we have with the GPL is that it doesn't allow us to link against proprietary libraries. However, as far as I am aware that is only an issue if the libs are required to run the program or are compile time linked. The user is allowed to combine a GPL program with non-GPL compatible plugins/modules for their use, but they are not allowed to distribute the resulting work.

If using NDI via the dynamic loading method, then the only new code we will introduce will be an MIT header, which is compatible with the GPL. So the resulting build of caspar will still be GPL compliant. It is only once the user combines it with the NDI runtime that the result will no longer be GPL compliant, but that only stops them distributing. They are still allowed to use it themselves.

I think we can ignore the bits of the license saying it needs to be in its own process/program, as that is only required if we want to be able to ship the NDI runtime with caspar. Ultimately GPL violations are fine if you only use it yourself, unless you are distributing the result.

TLDR; I believe we can use the NDI MIT headers, and ask the user to install the optional NDI runtime themselves if they wish without the project violating GPL.

I'm interested to know what others think of this.

Palakis commented 6 years ago

TLDR; I believe we can use the NDI MIT headers, and ask the user to install the optional NDI runtime themselves if they wish without the project violating GPL.

I definitely second you on this!

ahallez commented 5 years ago

For what it's worth, OBS as well as it's NDI integration plugin have a GPL v2 license. Both are available even if the discussion about the license compatibility is still open: https://github.com/Palakis/obs-ndi/issues/230

Julusian commented 5 years ago

A new NDI producer and consumer has been merged for 2.3 https://github.com/CasparCG/server/pull/1112