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.

jesperstarkar commented 9 years ago

Newteks new NDI protocol will be a better solution to IP infrastructure.

aircooled76 commented 9 years ago

+1 for this!

aircooled76 commented 9 years ago

Would it work to make a VNC based input to achive this?

TKooijmans commented 9 years ago

vnc is not fast enough! I saw NDI on tricaster on IBC and that works as fast as a normal SDI input!

aircooled76 commented 9 years ago

Just eead up on NDI... it is awesome... Would be great to build an NDI consumer and producer... very powerfull stuff!

Keksstar commented 8 years ago

+1

hummelstrand commented 8 years ago

The AirSend updater is supposed to update your system to be able to at least send over NDI, and forum users have reported that it works fine with CasparCG Server: http://pages.newtek.com/NDI-Upgrader-Download.html

mjbartholomew commented 8 years ago

Any idea on the undertaking to implement an NDI consumer and producer?

krzyc commented 8 years ago

How open is this NewTek's solution? Is it tied to Microsoft Windows as stated in minimum system requirements? Are there any limitations when using this protocol outside NewTek's ecosystem? How it is licensed?

I have applied for SDK access so I will probably get answers soon.

mjbartholomew commented 8 years ago

I have not attempted to gain SDK access, but I do know that Sienna has NDI apps for the iPad, iPhone and Mac OS X.

http://www.sienna-tv.com/ndi/

aircooled76 commented 8 years ago

vMix also has free NDI screen capture apps for windows and OSX at vmix.com

Very cool! On 18 Apr 2016 12:49 am, "Michael Bartholomew" notifications@github.com wrote:

I have not attempted to gain SDK access, but I do know that Sienna has NDI apps for the iPad, iPhone and Mac OS X.

http://www.sienna-tv.com/ndi/

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/CasparCG/Server/issues/379#issuecomment-211042989

Keksstar commented 8 years ago

html,body{font-size:12px;background-color:#fff;color:#333;font-family:sans-serif,Arial,Verdana,"Trebuchet MS";line-height:1.4;}I´m using the NDIMonitor direclty from Newtek as an Consumer. Works pretty well with the iVGA Interface from Caspar.

The way back in is missing :-/

aircooled76 schrieb am 17.04.2016 17:51:

vMix also has free NDI screen capture apps for windows and OSX at vmix.com

Very cool! On 18 Apr 2016 12:49 am, "Michael Bartholomew" notifications@github.com wrote:

I have not attempted to gain SDK access, but I do know that Sienna has NDI apps for the iPad, iPhone and Mac OS X.

http://www.sienna-tv.com/ndi/

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/CasparCG/Server/issues/379#issuecomment-211042989

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

 

Keksstar commented 8 years ago

If someone need it, I could provide the SDK to build an NDI producer. Would be great if someone could implement it :-)

Consumer doesn´t need to be builded in my eyes, cause the iVGA output is already working and works fine with the NDI AirSend Updater.

HellGore commented 8 years ago

It is in my TODO list and I already have the SDK. And by the way anyone can get the NDI SDK from NewTek.

dodgepong commented 8 years ago

Forgive my ignorance, but CasparCG is a GPL3 application, right? How would the distribution of an NDI producer work under under GPL3? It is my understanding that for GPL compatibility, NDI library/header sources would need to be distributable, and I don't believe the NDI SDK license allows for the distribution of their source files. Is there a plan to use some sort of inter-process communication to read NDI sources?

I ask because I am in a similar situation with a GPL program that wants to be able to take NDI inputs, and I am curious as to how CasparCG plans on solving this issue.

didikunz commented 8 years ago

Any news on this.

HellGore commented 8 years ago

I think we would do it in the same way as with the existing iVGA-support:

I don't remember if AirSend (iVGA) was considered a System Library or if we did a special exception for it, but anyway the reasoning should be the same with the full NDI SDK IMHO.

jesperstarkar commented 8 years ago

Thank you for the brilliant answer. Good to know!

didikunz commented 8 years ago

Aha, I was not concerned about the license issue, that is good to know. Just wanted to know, if the NDI input functionality is coming soon or not. Sorry of not expressing myself clearly. :)

HellGore commented 8 years ago

@didikunz yes, my answer was actually only in reply to the question asked by @dodgepong. You must have written your post while I was writing mine.

I have some code on my disk regarding this just to get a feel for the SDK but I have not spent time on it lately.

TKooijmans commented 8 years ago

Newtek has a tool called Transmit. With this tool any NDI source, desktop or window can be resend too a virtual Video and audio device. This virtual device can be seen as a capture device like a webcam by Skype etc. I have not tried this yet, but I think it's also possible to get it as input device for CasperCG

sesse commented 7 years ago

FWIW, FSF's position on proprietary plugins in GPL software is that they must run in different processes (https://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins). This specifically means that dlopen/GetProcAddress tricks do not change anything, and that GPLv3 software cannot link to NDI without a special exception (see below). These issues are murky, and what matters is what a judge would rule in court, but one could at least assume that as license writers, their interpretation would be heard and possibly given some weight. GPLv3 is somewhat clearer on this than GPLv2 was; the text now reads:

For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

You could discuss what “specifically meant to require” means, but again, FSF's FAQ here is clear on their own interpretation.

As for the other possibilities, NDI is obviously not a system library in the context of GPL. Again, the GPLv3 is clear on what's intended:

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

NDI is definitely no essential component of Windows or Linux (it's not even distributed with either), so a) falls.

The standard way of dealing with this is to grant a license exception (this is common for code that uses OpenSSL, and the GPLv3 section 7 explains how), but you would need to get every copyright holder of CasparCG (ie., everyone who has ever contributed any code, unless they have done copyright assignment) and any GPL code it uses, to agree to such an exception—one copyright holder cannot declare this unilaterally.

So my advice as a layman would be to make a producer that can publish to a pipe or shared memory segment under some defined protocol, and then have a separate NDI program that can read data from this protocol. (Similarly for consumers.) I understand this is inconvenient, but licenses don't really bow to wishful thinking. :-)

krzyc commented 7 years ago

Easiest option is to ask Newtek to relicense NDI SDK to GPLv2. Also I wonder if they already use some GPLv2 code in their libraries as it is common practice to abuse OSS licenses in commercial projects - there are not much success stories on fighting with these practises unfortunately.

But probably best option is to write GPLv2 compatible implementation of NDI - I do not know whether there will be patent issues or something.

By the way - are there same license issues for using Adobe, Bluefish and Decklink libraries by CasparCG?

dodgepong commented 7 years ago

NewTek recently released their headers under the MIT license, and made redistributables available for download from their site, which could possibly work if users want to take the extra step of downloading extra files from NewTek to enable NDI functionality.

sesse commented 7 years ago

NewTek has been asked to relicense their NDI SDK before, and has refused on the grounds of interoptability. Note that CasparCG is GPLv3, not GPLv2, so you'd need GPLv2+ or GPLv3(+) if so.

If people do the combination of CasparCG and non-free stuff themselves, that's fine, but the result becomes nondistributable (so you can use it yourself, but you can't e.g. sell a solution that's based on it). As for the status of Adobe, Bluefish and Decklink libraries, I'm less sure about the details for a variety of reasons, so I'll refrain from commenting.

RuneFog commented 7 years ago

In the latest SDK, NewTek has made a redistributable dynamic loadable library accessible:

DYNAMIC LOADING OF NDI LIBRARIES It is common that you do not want to link directly against the NDI libraries, but instead want to dynamically load them at run-time (which is of particular value in Open Source projects). There is a structure that contains all of the NDI entry points for a particular SDK version, and you can call a single entry point in the library to recover all of these functions. This would allow you on Windows for instance to use LoadLibrary to load the NDI DLL file and GetProcAddress to locate the single entry point. NDIlib_v2* p_NDILib = NDIlib_v2_load(); At this point, every NDI function has an equivalent member within the NDIlib_v2 structure. For instance, to initialize a sender you can replace a call to NDIlib_find_create2 in the following way: NDIlib_find_create2( … ) becomes p_NDILib->NDIlib_find_create2( … ) The preferred mechanism is that you include the NDI DLLs within your application install, but if you do not wish or cannot2 to distribute these then you can ask users to install the NDI redistributable that is both included within the SDK or available as a download from NewTek at http://new.tk/NDIRedistV2 .
When installed, the location of the redistributable can be found through the environment variable NDI_RUNTIME_DIR_V2. A full example is provided in the NDIlib_DynamicLoad that is included with the SDK and illustrates how to dynamically load the NDI libraries if they are available.

walterav1984 commented 7 years ago

@RuneFog I can confirm this Dynamic Loading Of NDI Libraries section is also listed in the linux NewTek NDI SDK version 2017-02-01 @ r73205.

However the URL to download the NDI redistributable http://new.tk/NDIRedistV2 is serving a MS Windows binary instead of a Linux one.

@HellGore Did you also receive the Newtek NDI SDK for linux besides the Windows SDK, it took me a different email address and a month of waiting before Newtek applied.

md5 9d1ebc495f603989cf0061a3d761b4f2 "NewTek NDI SDK (Linux).zip" #r72018
md5 0268b8dccaa662f6c043f47d73488db4 "NewTek NDI SDK (Linux).zip" #r73205
diegofromparis commented 7 years ago

+1

NDI Producer (input/ingest) is an important (must have) feature for CasparCG 2.1

nicoaguero commented 7 years ago

I add to the request that CasparCG Server 2.1 contains NDI for input, because it is something that would really be of great use to those who use CasparCG for their productions.

didikunz commented 7 years ago

As I can see from reading trough NDI's SDK documentation, there is a way to dynamically link in all neccessary dll's. That is made for all open source projects, that work with a different license, so that the user can download an install it. We use this mechanism alreday for sending out NDI. We can also use it for receiving NDI. So I see no reason, why it should give any licensing issues and would ask for integration of this feature asap, as I need it badly :)

vimlesh1975 commented 7 years ago

Yes. I also want to test this new feature if implemented.

sesse commented 7 years ago

As I can see from reading trough NDI's SDK documentation, there is a way to dynamically link in all neccessary dll's. […] So I see no reason, why it should give any licensing issues

See my comment on January 7th. Specifically the part starting with: “Loading runtime does not matter much for the license”

didikunz commented 7 years ago

We should stop the license discussion here, as if takes all these license terms by the word, we could stop CasparCG from beeing open source as also the BMD drivers are not open source etc. NewTek every year shows CasparCG's logo on their booth at IBC and so they want us to use their technology regardles of the exact terms. Also Flash player would need to be remove. Don't let us be "more catholic than the pope".

sesse commented 7 years ago

NewTek every year shows CasparCG's logo on their booth at IBC

CasparCG contains GPL code, and NewTek is in no position to excuse CasparCG from the GPL.

didikunz commented 7 years ago

HEADER FILES. (NDI_SDK_DIR\INCLUDE*.H) These files may be distributed with open source projects under the MIT license. These headers may be included in open source projects (see “Dynamic Loading” section for preferred mechanism), however the requirements of these projects in terms of visual identification of NDI shall be as outlined within the License section above.

RuneFog commented 7 years ago

Didi, newtek isn't the problem. The problem is that CasparCG has been released under a restrictive license that does not allow linking against closed sourced libraries unless, in sesses interpretation, anybody who has ever contributed signs an exception. This might be the letter of the gpl, but I'm not sure It's the spirit. If the developer base had been much smaller and closed group, it would be pretty easy to write the exception.

RuneFog commented 7 years ago

Actually, it seems that SVT is still copyright holder on (most of) the files.

sesse commented 7 years ago

Actually, it seems that SVT is still copyright holder on (most of) the files.

You don't need to write “Copyright ” to have copyright on a work; you get it automatically (since the Berne Convention in 1886). So even if the header says “Copyright SVT”, there will be a shared copyright between them and whoever else contributed to that file (even if they didn't add their own name), given that there hasn't been an explicit copyright assignment in place.

RuneFog commented 7 years ago

I still fail to see the difference between the decklink sdk and the ndi sdk. They're both MIT-like license APIs with propritary blobs. They both have the blobs available as separate downloads. As didi pointed out, the strict interpretation of the license would require removal of bmd support in casparcg.

berge commented 7 years ago

It's not entirely unreasonable (from a licence interpretation perspective) to argue that the BMD driver support in Caspar is out of compliance with GPLv3. The licence does allow linking against non-free system libraries that are "Major Components", but that definition is quite strict and excludes things like third-party drivers. Specifically (from section 1 of GPLv3):

A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

BMD drivers are not distributed with Windows, and are hardly an essential component of the operating system. The GPL FAQ is pretty explicit on this point. To allow linking against non-free system modules, an exception must be granted in the relevant files.

In the case of Caspar, I also think it's fair to argue that the author's intentions most likely was to allow this sort of usage, even though it's not explicitly in the licence. This probably doesn't impact anything, except – and I'm guessing wildly – in the event the project wants to add exceptions to the licence and can't get hold of every copyright holder. Maybe one can just assume that copyright holders for minor contributions would agree to add an exception. There may be precedent here, I don't know.

@RuneFog wrote:

I still fail to see the difference between the decklink sdk and the ndi sdk. They're both MIT-like license APIs with propritary blobs.

In the context of the GPL, I agree. However, personally I do think there's a distinct difference between the two: The decklink drivers are drivers in a very traditional and obvious sense of the word: They provide a software interface for hardware units, they do essentially nothing but providing that interface, and the hardware is virtually useless without. The NDI SDK, on the other hand, is not a driver; it's a software library that encodes and decodes video, sends it over the network (and other things), and it's useful without specific hardware.

(There's also an exception in the GPL for usage of (and thus linking against components that offer) interfaces that are official standards ("A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body[..]"). Such an example would be libc or OpenGL, so it's not relevant to this discussion.)

jesperstarkar commented 7 years ago

I only see 13 contributors listed here on Github. It might be misleading, coming from the SVN repo before migrating to Github. But if 13 is representable, a change of license driven by copyright holders should be doable.

berge commented 7 years ago

A change of licensing terms seems the right way forward.

13 contributors looks like the right ballpark. The git history goes back to 2010, and commits from 2010 to 2013 seems to have been imported from svn, including author information. Somewhat normalized (with a .mailmap file, see below), git shortlog says:

  1924  Robert Nagy
   633  Helge Norberg
    68  Niklas P. Andersson
    25  James Wise
    18  Zebiolo
     9  Walter Sonius
     8  Dimitry Ishenko
     6  krzyc
     5  Jonas Hummelstrand
     4  Antonio Ruano Cuesta
     3  Jesper Stærkær
     3  TK3
     2  Peter Keuter
     2  drakmor
     1  Ovidijus Striaukas

…of which at least seven authors' contributions are so trivial I doubt they're copyrightable (and would at any rate be trivial to re-implement).

I guess the interesting bit is the first commit, from 2010-09-14. It's 13k SLOC, commited by @ronag. It does not contain any licensing information (the LICENCE file was added in 2013), and it's not clear if he holds the copyright to all of that code. I don't know the project's early history; was it originally an internal project at SVT, later open sourced?

If the project decides to relicense, I'd suggest 1) someone comes up with a proper license suggestion (GPLv3 plus exceptions, for instance), 2) goes through the list of dependencies to make sure Caspar doesn't link against any pure-GPL-code (since GPL + exceptions in incompatible with pure GPL) and 3) then contacts all the copyright holders with a rationale and the suggestion.

.mailmap file for normalizing contributions:

Robert Nagy <ronag@362d55ac-95cf-4e76-9f9a-cbaa9c17b72d>
Helge Norberg <helge.norberg@gmail.com>
Helge Norberg <hellgore@362d55ac-95cf-4e76-9f9a-cbaa9c17b72d>
Niklas P. Andersson <niklas.p.andersson@svt.se>
Walter Sonius <walterav1984@gmail.com>
TK3 <tk-3@362d55ac-95cf-4e76-9f9a-cbaa9c17b72d>
Peter Keuter <Peter@Peter-PC.(none)>
jesperstarkar commented 7 years ago

ping @dotarmin

didikunz commented 7 years ago

CasparCG was a internal project before beeing open sourced. AFAIK Rober Nagy was the laed developer at that time. So as an employee it's normally the case, that your copyright goes to the company, that pays you. That is normally part of the contract. So for these early days I think SVT is the sole copyright holder. Of course that does not cover the contributions Robert made (and still do), after he left SVT and was a freelance developer.

jesperstarkar commented 7 years ago

Robert was not the initial developer, but everything prior to 2010 is SVT internally.

@berge Would a full blown permissive license be an option, if SVT want to go down that road. Could MIT fly?

berge commented 7 years ago

I'm just a random user with zero contributions to the project, so my opinion on this matters very little (-: However, I'd strongly recommend against a non-copyleft-license such as MIT or BSD. The graphics playout ecosystem seems to have few and mostly non-free offerings, often at considerable expense to users. With a non-copyleft license, there's a very real risk that Caspar will be forked to a (or several) non-free project(s), which definitely would not help the main project.

jesperstarkar commented 7 years ago

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

didikunz commented 7 years ago

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

It starts to becoume confusing :)

sesse commented 7 years ago

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.

dotarmin commented 7 years ago

@jesperstarkar Before I start commenting this issue I need to spend time on reading about the various licenses etc. I think it is really interesting that this issue has got attention again!

The comments and discussions so far has been interesting, I will spend little time to read more about various licenses etc.to get involved into this discussion.