Message ID | CAB0OVGpkpyFzmkuC+kO3-Er3iNYH9hpO4zDTQZbRpEyFu=fjuQ@mail.gmail.com |
---|---|
State | Accepted |
Headers | show |
Hello there, Has Newtek NDI been given a chance to rectify this from their end? This is clearly a license violation, but taking drastic steps such as stripping support for their protocols is a knee jerk reaction. Let them respond before merging this PR. Regards, Dennis. On Mon, Dec 3, 2018, 19:06 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: > Hi! > > It appears to me that NewTek abused our willingness to add an optional > external nonfree library, I don't see many better options. See Ticket > #7589 and a blog post by a NewTek engineer confirming the issue. > > Patch untested. > > Please comment, Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
On 03-12-2018 09:35 PM, Carl Eugen Hoyos wrote: > Hi! > > It appears to me that NewTek abused our willingness to add an optional > external nonfree library, I don't see many better options. See Ticket > #7589 and a blog post by a NewTek engineer confirming the issue. What's the link to the blog post? Also, is anyone from Newtek on the ML - if not, is there someone we can invite for input? Gyan
2018-12-03 17:16 GMT+01:00, Gyan Doshi <gyandoshi@gmail.com>: > On 03-12-2018 09:35 PM, Carl Eugen Hoyos wrote: >> Hi! >> >> It appears to me that NewTek abused our willingness to add an optional >> external nonfree library, I don't see many better options. See Ticket >> #7589 and a blog post by a NewTek engineer confirming the issue. I should clarify that I did not verify the issue myself, ie in theory it could be that NewTek does not distribute non-free binaries based on FFmpeg source code. > What's the link to the blog post? > Also, is anyone from Newtek on the ML - if not, is there someone we > can invite for input? What kind of input would seem useful to you in this case? Carl Eugen
On 03-12-2018 09:49 PM, Carl Eugen Hoyos wrote: > 2018-12-03 17:16 GMT+01:00, Gyan Doshi <gyandoshi@gmail.com>: > >> What's the link to the blog post? > >> Also, is anyone from Newtek on the ML - if not, is there someone we >> can invite for input? > > What kind of input would seem useful to you in this case? Insight on what they were thinking. If it's a careless oversight, it can be remedied and this patch is not needed. But we should hear from them, ideally. Gyan
2018-12-03 17:13 GMT+01:00, Dennis Mungai <dmngaie@gmail.com>: > Has Newtek NDI been given a chance to rectify this from their end? Why do you believe that this would be a useful way to go? > This is clearly a license violation, but taking drastic steps such > as stripping support for their protocols is a knee jerk reaction. Why? Have you ever dealt with open-source license violations? Please do not top-post here, Carl Eugen
On Mon, Dec 3, 2018 at 11:16 AM Gyan Doshi <gyandoshi@gmail.com> wrote: > On 03-12-2018 09:35 PM, Carl Eugen Hoyos wrote: > > It appears to me that NewTek abused our willingness to add an optional > > external nonfree library, I don't see many better options. See Ticket > > #7589 and a blog post by a NewTek engineer confirming the issue. > > What's the link to the blog post? https://www.newtek.com/blog/introducing-ndi-3-5/ > ... and we even include FFMPEG for Windows with NDI support for your convenience, eliminating the hassle of working out how to compile it yourself.
Carl, If it is indeed an abuse of the license terms, as you've purported, it would be wise to get their input on this, as Gyan Doshi has elaborated above. They are contributors to this project, and it falls to reason that the burden of addressing this falls on them. Moving forward with such drastic steps only portrays arrogance , which is uncalled for. I've seen contributors here deal with the likes of Amazon (the recent NGCodec patch license issue comes to mind) and had that issue resolved in an amicable manner. So why can't the same be done with Newtek? On Mon, Dec 3, 2018, 19:24 Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: > 2018-12-03 17:13 GMT+01:00, Dennis Mungai <dmngaie@gmail.com>: > > > Has Newtek NDI been given a chance to rectify this from their end? > > Why do you believe that this would be a useful way to go? > > > This is clearly a license violation, but taking drastic steps such > > as stripping support for their protocols is a knee jerk reaction. > > Why? > Have you ever dealt with open-source license violations? > > Please do not top-post here, Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
Kyle Schwarz (2018-12-03): > https://www.newtek.com/blog/introducing-ndi-3-5/ > > > ... and we even include FFMPEG for Windows with NDI support for your convenience, eliminating the hassle of working out how to compile it yourself. That is not how it is supposed to work. If they want to include FFmpeg for their users' convenience, they have to make their software LGPL-compatible. Because "their users' convenience" is good publicity for them, they have to pay for it, not us. Regards,
In this case , Carl's decision to strip their code from FFmpeg is valid. This is a clear violation of the license terms. On Mon, Dec 3, 2018, 19:38 Nicolas George <george@nsup.org wrote: > Kyle Schwarz (2018-12-03): > > https://www.newtek.com/blog/introducing-ndi-3-5/ > > > > > ... and we even include FFMPEG for Windows with NDI support for your > convenience, eliminating the hassle of working out how to compile it > yourself. > > That is not how it is supposed to work. If they want to include FFmpeg > for their users' convenience, they have to make their software > LGPL-compatible. > > Because "their users' convenience" is good publicity for them, they have > to pay for it, not us. > > Regards, > > -- > Nicolas George > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
Dennis Mungai (2018-12-03): > In this case , Carl's decision to strip their code from FFmpeg is valid. > This is a clear violation of the license terms. Indeed. And please stop top-posting. If you do not know what it means, look it up. Regards,
I contacted NewTek about this, here's the pretty much immediate response I got: On 03.12.2018 18:55, Andrew Cross <across@newtek.com> wrote: > Yikes, I am pretty surprised by this to be honest I think that our intent might have been entirely misconstrued. > > We are in no way trying to abuse anything anyone did and if they want us to not distribute FFMPEG then we'd be very happy to stop doing that ... we did this purely as a public service because loads of people complained (hundreds) to use about NDI not being part of the FFMPEG nightly builds. We had initially tried to help make it part of the nightly builds but got a lot of push-back and it did not seem worth the fight (our headers are MIT licensed and you can download our run-times for free, so it is no different than say nvEnc, etc... that are all parts of the builds). At the end of the day, we make no money of NDI and just give it away and support it for free so it is hardly part of an evil ploy to corrupt anyone ;) > > I'd prefer not to jump in the middle of the thread, but we are happy to work with anyone on this, our only goal is to serve people using NDI and if FFMPEG do not want us to distribute it then we're happy to do that, likewise if they want us to change the options we're also happy to do that. We'd be happy to do what we reasonably can for it to be part of the nightly builds as well ... > > Feel free to pass this along and anyone can email me directly who wants too. > > Andrew I think the easiest way out here would be to make an LGPL build instead? libndi can still be enabled then, but the build isn't nonfree. libx264 would have to go, but that's probably still better for them than removing ffmpeg entirely.
2018-12-03 19:12 GMT+01:00, Timo Rothenpieler <timo@rothenpieler.org>: > I contacted NewTek about this, here's the pretty much immediate response > I got: > > On 03.12.2018 18:55, Andrew Cross <across@newtek.com> wrote: >> Yikes, I am pretty surprised by this to be honest I think that our intent >> might have been entirely misconstrued. (Note that this is hard to believe but this is not relevant.) >> We are in no way trying to abuse anything anyone did and if they want us >> to not distribute FFMPEG then we'd be very happy to stop doing that ... we >> did this purely as a public service because loads of people complained >> (hundreds) to use about NDI not being part of the FFMPEG nightly builds. >> We had initially tried to help make it part of the nightly builds but got >> a lot of push-back and it did not seem worth the fight (our headers are >> MIT licensed and you can download our run-times for free, so it is no >> different than say nvEnc, etc... that are all parts of the builds). At the >> end of the day, we make no money of NDI and just give it away and support >> it for free so it is hardly part of an evil ploy to corrupt anyone ;) >> >> I'd prefer not to jump in the middle of the thread, but we are happy to >> work with anyone on this, our only goal is to serve people using NDI and >> if FFMPEG do not want us to distribute it then we're happy to do that, >> likewise if they want us to change the options we're also happy to do >> that. We'd be happy to do what we reasonably can for it to be part of the >> nightly builds as well ... >> >> Feel free to pass this along and anyone can email me directly who wants >> too. Don't you agree that there is something missing in this message? >> Andrew > I think the easiest way out here would be to make an LGPL build instead? What kind of message does this send to future license violators? Carl Eugen
On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > Hi! > > It appears to me that NewTek abused our willingness to add an optional > external nonfree library, I don't see many better options. See Ticket > #7589 and a blog post by a NewTek engineer confirming the issue. > > Patch untested. > > Please comment, Carl Eugen On the general idea of this - agreed. Separately I think we should at least bring up a possible rethink of our policy about non-open source nonfree components. If it's: - Not part of the OS or - Not open source ...maybe we should not include such a component upstream? Best regards, Jan
On 12/3/18, Jan Ekström <jeebjp@gmail.com> wrote: > On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> >> Hi! >> >> It appears to me that NewTek abused our willingness to add an optional >> external nonfree library, I don't see many better options. See Ticket >> #7589 and a blog post by a NewTek engineer confirming the issue. >> >> Patch untested. >> >> Please comment, Carl Eugen > > On the general idea of this - agreed. > > Separately I think we should at least bring up a possible rethink of > our policy about non-open source nonfree components. > > If it's: > - Not part of the OS > or > - Not open source > > ...maybe we should not include such a component upstream? Yes, remove all hardware stuff +1.
On Mon, Dec 3, 2018 at 8:48 PM Paul B Mahol <onemda@gmail.com> wrote: > > On 12/3/18, Jan Ekström <jeebjp@gmail.com> wrote: > > On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > >> > >> Hi! > >> > >> It appears to me that NewTek abused our willingness to add an optional > >> external nonfree library, I don't see many better options. See Ticket > >> #7589 and a blog post by a NewTek engineer confirming the issue. > >> > >> Patch untested. > >> > >> Please comment, Carl Eugen > > > > On the general idea of this - agreed. > > > > Separately I think we should at least bring up a possible rethink of > > our policy about non-open source nonfree components. > > > > If it's: > > - Not part of the OS > > or > > - Not open source > > > > ...maybe we should not include such a component upstream? > > Yes, remove all hardware stuff +1. That's something different, though. - dxva2 and d3d11va are Windows APIs, thus fall under "OS" - VT on mac/iOS does the same - vaapi and the kernel API seem to be compatible with GPL (at least currently), so they would stay. - out of similar things such as NDI, SRT seems to be open source now? Jan
On Mon, Dec 3, 2018, 9:48 PM Paul B Mahol <onemda@gmail.com wrote: > On 12/3/18, Jan Ekström <jeebjp@gmail.com> wrote: > > On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> > wrote: > >> > >> Hi! > >> > >> It appears to me that NewTek abused our willingness to add an optional > >> external nonfree library, I don't see many better options. See Ticket > >> #7589 and a blog post by a NewTek engineer confirming the issue. > >> > >> Patch untested. > >> > >> Please comment, Carl Eugen > > > > On the general idea of this - agreed. > > > > Separately I think we should at least bring up a possible rethink of > > our policy about non-open source nonfree components. > > > > If it's: > > - Not part of the OS > > or > > - Not open source > > > > ...maybe we should not include such a component upstream? > > Yes, remove all hardware stuff +1. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > While there is a non-free option and while there are lots of HW related > implementations done by developers in such condition for long time, I > believe it is not right to remove all thesd valuable work. This will > definitely break to courage to submit new developments to FFmpeg. I also think, Newtek is not in a way to hide things as they share the post. I believe they thought their approach is normal, when considering the current case examples.
2018-12-03 21:28 GMT+01:00, Martin Vignali <martin.vignali@gmail.com>: >> > >> >> > >> It appears to me that NewTek abused our willingness to add an >> > >> optional >> > >> external nonfree library, I don't see many better options. See Ticket >> > >> #7589 and a blog post by a NewTek engineer confirming the issue. >> > >> >> > >> Patch untested. >> > >> >> > >> Please comment, Carl Eugen >> > > >> > > This patch looks wrong to me. > > It's seems like removing features for personal opinion. This is a lie. (I don't care.) > Ticket 7589, mention an incorrect build redistribution. > > So, right way to fix this ticket, will be (for people interesting in this > kind of thing) > to indicate, what need to be done, in order to have a licence compliant > build. Again: What message would this send to future license violators? Since you are throwing accusations: Please remind me how many license violations you have worked on. Carl Eugen
Jan Ekström (2018-12-03): > Separately I think we should at least bring up a possible rethink of > our policy about non-open source nonfree components. > > If it's: > - Not part of the OS > or > - Not open source > > ...maybe we should not include such a component upstream? I agree. Maybe we can make an exception when the non-free upstream is dead yet useful, like faac was for some time. But for contributors like this NDI thing, either they make the build components (L)GPL-compatible or they do not enjoy the benefit of being included. Regards,
On Mon, Dec 3, 2018, 11:41 PM Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: > 2018-12-03 21:28 GMT+01:00, Martin Vignali <martin.vignali@gmail.com>: > >> > >> > >> > >> It appears to me that NewTek abused our willingness to add an > >> > >> optional > >> > >> external nonfree library, I don't see many better options. See > Ticket > >> > >> #7589 and a blog post by a NewTek engineer confirming the issue. > >> > >> > >> > >> Patch untested. > >> > >> > >> > >> Please comment, Carl Eugen > >> > > > >> > > > > This patch looks wrong to me. > > > > It's seems like removing features for personal opinion. > > This is a lie. > (I don't care.) > > > Ticket 7589, mention an incorrect build redistribution. > > > > So, right way to fix this ticket, will be (for people interesting in this > > kind of thing) > > to indicate, what need to be done, in order to have a licence compliant > > build. > > Again: What message would this send to future license violators? > > Since you are throwing accusations: > Please remind me how many license violations you have worked on. > > Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Newtek representative says, they will remove the binary from SDK right away and will stop distributing as its current state with passing their apologies, while accepting their mistake. I do not understand that how it is being decided to remove a complete work against a non-free distribution. I suggest to not to take immediate harsh actions without fully discussing the side effects. Personally, I do not believe they break the license on purpose. If so, they wouldn't announce it. They would fo as some others do, by trying hide. So personally, I think removal of code is a very strong decision for this kind of revertible violation, as Newtek also gets in response asap.
On 12/3/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2018-12-03 21:28 GMT+01:00, Martin Vignali <martin.vignali@gmail.com>: >> Ticket 7589, mention an incorrect build redistribution. >> >> So, right way to fix this ticket, will be (for people interesting in this >> kind of thing) >> to indicate, what need to be done, in order to have a licence compliant >> build. > > Again: What message would this send to future license violators? > > Since you are throwing accusations: > Please remind me how many license violations you have worked on. What is this now? Why are you still here?
Ali KIZIL (2018-12-04): > Personally, I do not believe they break the license on purpose. If so, they They are a commercial entity, they have a legal department. "Not on purpose" is not an excuse for them. > wouldn't announce it. They would fo as some others do, by trying hide. So > personally, I think removal of code is a very strong decision for this > kind of revertible violation, as Newtek also gets in response asap. The only acceptable response from them now is to comply with the GPL. This is exactly how the GPL is stated: a failure to comply with the copyleft clauses rescinds all rights to use the original GPLed code. Note that they did not only infringe on FFmpeg's license, they also infringed on x264. Regards,
2018-12-03 22:00 GMT+01:00, Ali KIZIL <alikizil@gmail.com>: > Newtek representative says, they will remove the binary from SDK right away Could you please read the sentence you sent? Particularly the words "says" and "will". They did not remove the binariy when informed about the license violations! (At least, there is no indication they did.) > Personally, I do not believe they break the license on purpose. Did you read the post on their support forum where the very person claiming now he had no idea it is wrong answered to the information that distributing such binaries is illegal? Carl Eugen
On Mon, Dec 3, 2018 at 10:29 PM Martin Vignali <martin.vignali@gmail.com> wrote: > > This patch looks wrong to me. > > It's seems like removing features for personal opinion. > > Ticket 7589, mention an incorrect build redistribution. > > So, right way to fix this ticket, will be (for people interesting in this > kind of thing) > to indicate, what need to be done, in order to have a licence compliant > build. > And if building in LGPL, it's a solution for provide a right binary, > doesn't really understand, what > it's not better mention in this ticket. > Actually, I'm not 100% sure if a closed source blob is LGPL compatible this way - although the other way a closed source blob can include an LGPL component as long as they provide the sources and the means to replace the LGPL component (aka either shared libraries, or object files for static linking). I don't remember who exactly was it whom planted this idea in my mind (unrelated to NDI completely for the record), but it did pop up in some discussion. Hopefully that someone can chime in once again if he notices this. > And if some people have personal issue with this company, i doesn't think > this mailing list and trac it's really the right place for discussing it. > I think rather than having an issue with the company, some people are having an issue with how it seems to have dealt with people who have attempted to implement their protocol in open source (legal threats were mentioned). Whether that is true or not I do not know, but as far as I last saw on the issue tracker's thread there seems to be an attempt of making it look better than it is. I remember looking at their site and seeing their solution being marketed as a "standard", yet there was no specification and they clearly were only interested in their blob. But knowing nothing much else, it was mostly on the "meh" level and thus I did not enough strength to put enough care into looking into it more (at the time of the patches). > I agree with Ali Kizil, > And the answer of newtek looks not so bad for me. > The problem is maybe a licence violation (don't know and don't care), > but it's very far away of selling a software with licence violation in it. > > This kind of agressive patch, send a very strange signal to current and > future contributors/users. > Yes, I agree. We should have a more clear policy on non-OSS contributions. Although to be completely honest the whole FFmpeg development process is a mess. But I think we should keep this discussion to NDI. > FFmpeg keep some options for compatibility in long term, but can remove a > future useful for some people so fast (just because some people would like > to send a sanction/message) ? If you think NDI is useful, I dearly hope you agree that it would be more useful to you compatible with OSS licenses. Or even more so if it was open source. Jan
On Tue, Dec 4, 2018, 12:07 AM Carl Eugen Hoyos <ceffmpeg@gmail.com wrote: > 2018-12-03 22:00 GMT+01:00, Ali KIZIL <alikizil@gmail.com>: > > > Newtek representative says, they will remove the binary from SDK right > away > > Could you please read the sentence you sent? > Particularly the words "says" and "will". > > They did not remove the binariy when informed about the > license violations! > (At least, there is no indication they did.) > > > Personally, I do not believe they break the license on purpose. > > Did you read the post on their support forum where the very > person claiming now he had no idea it is wrong answered to > the information that distributing such binaries is illegal? > > Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel https://trac.ffmpeg.org/ticket/7589 Sent by across: ... If we have offended anyone then I sincerely apologize and please accept that it was not our intent. We will remove FFMPEG entirely from our SDK and get it patched online today. ... > > I didn't read the forums, yet I take care of what he is saying and if they > are going to remove compiled binary from their SDK with an official > apology.
On Mon, 3 Dec 2018, Carl Eugen Hoyos wrote: > Hi! > > It appears to me that NewTek abused our willingness to add an optional > external nonfree library, I don't see many better options. See Ticket > #7589 and a blog post by a NewTek engineer confirming the issue. You should think about our users who compile and use ffmpeg with NDI. This change affects them negatively, so I don't support it. Regards, Marton
On Mon, 3 Dec 2018, at 17:05, Carl Eugen Hoyos wrote: > It appears to me that NewTek abused our willingness to add an optional > external nonfree library, I don't see many better options. See Ticket > #7589 and a blog post by a NewTek engineer confirming the issue. +1, please apply. Newtek is a big bully against open source developers, threatening to sue. This is a violation, done on purpose (see the message when running the binary, and see the blogpost where they knew about it for months), of both FFmpeg and maybe x264. Keeping this wrapper just helps people violate the FFmpeg license and the GPL. Best,
On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote: > > On the general idea of this - agreed. > > > > Separately I think we should at least bring up a possible rethink of > > our policy about non-open source nonfree components. > > > > If it's: > > - Not part of the OS > > or > > - Not open source > > > > ...maybe we should not include such a component upstream? > > Yes, remove all hardware stuff +1. Libraries to access hardware, notably those that are talking directly with something that was shipped with the drivers, are usually considered part of the OS. This is a bit weird, but this extend the Linux way to other (broken) OSes. That would make nvenc and such acceptable. NDI is not hardware. (Nor is faac)
> Again: What message would this send to future license violators?
A bad one.
I would remove this.
On Mon, 3 Dec 2018, Jean-Baptiste Kempf wrote: > On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote: >> > On the general idea of this - agreed. >> > >> > Separately I think we should at least bring up a possible rethink of >> > our policy about non-open source nonfree components. >> > >> > If it's: >> > - Not part of the OS >> > or >> > - Not open source >> > >> > ...maybe we should not include such a component upstream? >> >> Yes, remove all hardware stuff +1. > > Libraries to access hardware, notably those that are talking directly with something that was shipped with the drivers, are usually considered part of the OS. This is a bit weird, but this extend the Linux way to other (broken) OSes. > > That would make nvenc and such acceptable. > > NDI is not hardware. (Nor is faac) I really don't want to troll here, but there is an NDI PTZ camera: https://www.newtek.com/camera/ndihx-ptz1/ So is it really that different to a USB camera just because the singalling is going through ethernet and not USB? Regards, Marton
On Tue, Dec 4, 2018, 1:14 AM Marton Balint <cus@passwd.hu wrote: > > > On Mon, 3 Dec 2018, Jean-Baptiste Kempf wrote: > > > On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote: > >> > On the general idea of this - agreed. > >> > > >> > Separately I think we should at least bring up a possible rethink of > >> > our policy about non-open source nonfree components. > >> > > >> > If it's: > >> > - Not part of the OS > >> > or > >> > - Not open source > >> > > >> > ...maybe we should not include such a component upstream? > >> > >> Yes, remove all hardware stuff +1. > > > > Libraries to access hardware, notably those that are talking directly > with something that was shipped with the drivers, are usually considered > part of the OS. This is a bit weird, but this extend the Linux way to other > (broken) OSes. > > > > That would make nvenc and such acceptable. > > > > NDI is not hardware. (Nor is faac) > > I really don't want to troll here, but there is an NDI PTZ camera: > > https://www.newtek.com/camera/ndihx-ptz1/ > > So is it really that different to a USB camera just because the > singalling is going through ethernet and not USB? > > Regards, > Marton > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel +1 or PCIe Just a suggestion: there can be a request from well known brands who are making contributions to FFmpeg to donate for hiring a lawyer who has proficiency on OSS subject for both US and EU laws. It will be for their and community's benefit, as there will be an independent point of view. I believe there can be donators from community too. Time to time, it is noticable users as asking for non-free compile subject. This approach can bring a proper action for similar cases and avoid in further. The lawyer can be supportive on CoC subject either. > >
On Mon, 3 Dec 2018, at 23:14, Marton Balint wrote: > On Mon, 3 Dec 2018, Jean-Baptiste Kempf wrote: > > On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote: > > Libraries to access hardware, notably those that are talking directly with something that was shipped with the drivers, are usually considered part of the OS. This is a bit weird, but this extend the Linux way to other (broken) OSes. > > > > That would make nvenc and such acceptable. > > > > NDI is not hardware. (Nor is faac) > > I really don't want to troll here, but there is an NDI PTZ camera: > > https://www.newtek.com/camera/ndihx-ptz1/ > > So is it really that different to a USB camera just because the > singalling is going through ethernet and not USB? Yes, because NDI is a network protocol. Those cameras exposes streams, like RTSP. They are servers, so they are not part of your machine.
There is a mix of several discussion in this thread, which need to be discuss separately. 1 - Licence violation on a build. 2 - Opinion on Newtek behaviour 3 - Inclusion of non open source part 4 - Removal of libndi device 1 : Doesn't really understand, how this licence violation can be fix in modifying the source code. Removing features used by people which doesn't respect the licence, seems a very bad thing. 2 - Nothing to do in this mailing list. Except trying to influence technical aspect, with emotional stuff. "It appears to me that NewTek abused our willingness..." or "Newtek is a big bully against open source developers, threatening to sue." is not really what we can call "a technical argument". The choice of adding or removing a feature, is (i hope) not link, to the behaviour of the original creator. 3 - Need a proper definition, and a dedicated discussion. To avoid including code that it's not conform to the global policy of this project. Reading this thread, it's seems like there is lot of interpretation about acceptable and non acceptable not opensource part. - ok for not open source part from os - ok for not open source part for "hardware thing", because we can think it's like os thing ! - ok from not open source part, if it's useful ? or not ? What definition of useful ? (and everything related to broadcast is not useless, just because not everyone use it !) 4 - libndi device is part of ffmpeg for now. Removing it without at least a deprecation period, will just break by surprise every working tools based on that even for user who respect the terms of the licence and build themselves ffmpeg with this support (like mention by Marton Balint). Bad message send to people who respect the licence ! :-) And yes, it's better to have full opensource ndi support, instead of the current situation. But it's not a reason to remove features for users. Martin
2018-12-04 15:00 GMT+01:00, Martin Vignali <martin.vignali@gmail.com>: > There is a mix of several discussion in this thread, which need to be > discuss separately. > > 1 - Licence violation on a build. [...] > 1 : > Doesn't really understand, how this licence violation can be fix in > modifying the source code. Where was this claimed / who thinks so? Carl Eugen
Helllo, On Tue, 4 Dec 2018, at 15:00, Martin Vignali wrote: > 1 : > Removing features used by people which doesn't respect the licence, seems a > very bad thing. I disagree with you. Helping people violating open source licenses is not a good idea. > 3 - Need a proper definition, and a dedicated discussion. To avoid > including code that it's not conform to the global policy of this project. > Reading this thread, it's seems like there is lot of interpretation about > acceptable and non acceptable not opensource part. The thing is, the license is the license, and there are a lot of explanations from FSF, FSFE, SFLC, and sooo many others. > - ok for not open source part from os > - ok for not open source part for "hardware thing", because we can think > it's like os thing ! Yes, and this is quite documented, as part of all the GPL family of licenses, as part of "System Libraries". > - ok from not open source part, if it's useful ? or not ? > What definition of useful ? (and everything related to broadcast is not > useless, just because not everyone use it !) You cannot define usefulness easily. > And yes, it's better to have full opensource ndi support, instead of the > current situation. > But it's not a reason to remove features for users. But then, you will get absolutely all the integration from ALL the various non-open source multimedia libraries, because it is useful to someone. Including shims for Adobe, Dolby and others. And what is the incentive to do open source alternatives?
Le mar. 4 déc. 2018 à 16:12, Jean-Baptiste Kempf <jb@videolan.org> a écrit : > Helllo, > > On Tue, 4 Dec 2018, at 15:00, Martin Vignali wrote: > > 1 : > > Removing features used by people which doesn't respect the licence, > seems a > > very bad thing. > > I disagree with you. > Helping people violating open source licenses is not a good idea. > It's not just about helping Newtek or not. My intervention in this discussion is mainly about annoy ndi/ffmpeg user (including those who respect licence) Of course Newtek have some interest of having ndi support inside ffmpeg but some user can also have an interest to have this feature. It's similar for me to other manufacturer things (for example decklink device support have a benefit for blackmagic and for user who need SDI record/playback). > > > 3 - Need a proper definition, and a dedicated discussion. To avoid > > including code that it's not conform to the global policy of this > project. > > Reading this thread, it's seems like there is lot of interpretation about > > acceptable and non acceptable not opensource part. > > The thing is, the license is the license, and there are a lot of > explanations from FSF, FSFE, SFLC, and sooo many others. > > > - ok for not open source part from os > > - ok for not open source part for "hardware thing", because we can think > > it's like os thing ! > > Yes, and this is quite documented, as part of all the GPL family of > licenses, as part of "System Libraries". > > > - ok from not open source part, if it's useful ? or not ? > > What definition of useful ? (and everything related to broadcast is not > > useless, just because not everyone use it !) > > You cannot define usefulness easily. > That's exactly what I meant. For including or not, some not opensource part, there will be two case - the part which can be included in redistributable build (i let people who have knowledge on this to decide which part can be in these builds) - the part which can not be included in redistributable build, and need that the user compile himself to enable some functionnality. If this is just about having the right (in licence point of view) to include or not in these kind of build, here too i will let people with licence knowledge decide. But if including or not, a not opensource part, it's about opinion on utility of this part, this need to be better define. This will avoid discussion about being useful or not, depending of opinion of each one at the moment of a patch submission. An impartial way, can be for example, if the component is free (in the sense without additionnal cost) and provide a functionality not available in another way. > > And yes, it's better to have full opensource ndi support, instead of the > > current situation. > > But it's not a reason to remove features for users. > > But then, you will get absolutely all the integration from ALL the various > non-open source multimedia libraries, because it is useful to someone. > Including shims for Adobe, Dolby and others. > I'm probably disagree with you on this subject ! :-) > And what is the incentive to do open source alternatives? > > In a manufacturer point of view : having the functionnality available to a wider audience, because it can be included in distributable build. In user/contributor point of view : having more sustainability on a feature. A full opensource code can still working if some people have an interest of maintain/improve it. Martin
Hi, On Tue, Dec 4, 2018 at 4:56 PM Martin Vignali <martin.vignali@gmail.com> wrote: > Le mar. 4 déc. 2018 à 16:12, Jean-Baptiste Kempf <jb@videolan.org> a > écrit : > > > But then, you will get absolutely all the integration from ALL the > various > > non-open source multimedia libraries, because it is useful to someone. > > Including shims for Adobe, Dolby and others. > > I'm probably disagree with you on this subject ! :-) > https://patchwork.ffmpeg.org/patch/7329/ (see also my response to that [1]) Or just on IRC today (!) "<LigH> JVET VVC just got ready to be built with MSYS/MinGW too ... so I guess it is not yet in a stage to be considered to be linked into ffmpeg. What would be your criteria to consider this encoder? How would we get to know that you start considering it? Looking for a thread in the mailing list?" I'm surprised this patch made it in, I've always assumed we were uncomfortable with closed-source software and that the hardware-support was a corner-case. Can I submit a wrapper for my closed-source VP9 encoder? Ronald [1] https://ffmpeg-devel.ffmpeg.narkive.com/Ok5y3HXO/patch-0-3-codec-wrapper-for-librv11-and-rmhd-muxer-demuxer#post35
Marton Balint (2018-12-03): > You should think about our users who compile and use ffmpeg with NDI. This > change affects them negatively, so I don't support it. They chose to use hardware that only works with non-free software. They made their bed. I support the removal. Regards,
On Tue, 4 Dec 2018, at 22:50, Martin Vignali wrote: > > But then, you will get absolutely all the integration from ALL the various > > non-open source multimedia libraries, because it is useful to someone. > > Including shims for Adobe, Dolby and others. > > I'm probably disagree with you on this subject ! :-) Then, this is the crux of the discussion: do you want every non-open-source library to be in FFmpeg? For hardware acceleration and drivers, the cut is quite clear. For the rest, I'm not so sure. If so, be prepared for a LOT of patches, for everything under the world, starting with librv11, and Eve and so on.
2018-12-03 17:05 GMT+01:00, Carl Eugen Hoyos <ceffmpeg@gmail.com>: > It appears to me that NewTek abused our willingness to add an optional > external nonfree library, I don't see many better options. See Ticket > #7589 and a blog post by a NewTek engineer confirming the issue. > > Patch untested. After several people have objected claiming NewTek would fix this situation, a week has passed: No visible reaction whatsoever, not even requesting more time. What are those suggesting who were against this patch? Carl Eugen
On 10-12-2018 07:41 AM, Carl Eugen Hoyos wrote: > 2018-12-03 17:05 GMT+01:00, Carl Eugen Hoyos <ceffmpeg@gmail.com>: > >> It appears to me that NewTek abused our willingness to add an optional >> external nonfree library, I don't see many better options. See Ticket >> #7589 and a blog post by a NewTek engineer confirming the issue. >> >> Patch untested. > After several people have objected claiming NewTek would fix this > situation, a week has passed: No visible reaction whatsoever, not > even requesting more time. > > What are those suggesting who were against this patch? Contact Newtek with your concerns and a deadline and what action you're considering beyond the deadline. Gyan
Gyan <ffmpeg@gyani.pro>, 10 Ara 2018 Pzt, 11:47 tarihinde şunu yazdı: > > On 10-12-2018 07:41 AM, Carl Eugen Hoyos wrote: > > 2018-12-03 17:05 GMT+01:00, Carl Eugen Hoyos <ceffmpeg@gmail.com>: > > > >> It appears to me that NewTek abused our willingness to add an optional > >> external nonfree library, I don't see many better options. See Ticket > >> #7589 and a blog post by a NewTek engineer confirming the issue. > >> > >> Patch untested. > > After several people have objected claiming NewTek would fix this > > situation, a week has passed: No visible reaction whatsoever, not > > even requesting more time. > > > > What are those suggesting who were against this patch? > > Contact Newtek with your concerns and a deadline and what action you're > considering beyond the deadline. > > Gyan Newtek released 3.7.1 version of their SDK which does not include ffmpeg.exe md5sum is: e2a29174333f20cb6cc66ec5e27ccbf3 Downloads/NewTek NDI 3.7.1 SDK.exe
2018-12-10 9:46 GMT+01:00, Gyan <ffmpeg@gyani.pro>: > > On 10-12-2018 07:41 AM, Carl Eugen Hoyos wrote: >> 2018-12-03 17:05 GMT+01:00, Carl Eugen Hoyos <ceffmpeg@gmail.com>: >> >>> It appears to me that NewTek abused our willingness to add an optional >>> external nonfree library, I don't see many better options. See Ticket >>> #7589 and a blog post by a NewTek engineer confirming the issue. >>> >>> Patch untested. >> After several people have objected claiming NewTek would fix this >> situation, a week has passed: No visible reaction whatsoever, not >> even requesting more time. >> >> What are those suggesting who were against this patch? > > Contact Newtek with your concerns and a deadline and what > action you're considering beyond the deadline. Done. Thank you, Carl Eugen
From 48ecad006fcd9db4558d1d23482e37006805bf1e Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos <ceffmpeg@gmail.com> Date: Mon, 3 Dec 2018 17:01:59 +0100 Subject: [PATCH] lavd: Remove libndi_newtek --- Changelog | 1 + configure | 7 - libavdevice/Makefile | 2 - libavdevice/libndi_newtek_common.h | 30 ---- libavdevice/libndi_newtek_dec.c | 342 ------------------------------------ libavdevice/libndi_newtek_enc.c | 299 ------------------------------- libavdevice/version.h | 4 +- 7 files changed, 3 insertions(+), 682 deletions(-) delete mode 100644 libavdevice/libndi_newtek_common.h delete mode 100644 libavdevice/libndi_newtek_dec.c delete mode 100644 libavdevice/libndi_newtek_enc.c diff --git a/Changelog b/Changelog index 1f53ff4..ad03f43 100644 --- a/Changelog +++ b/Changelog @@ -10,6 +10,7 @@ version <next>: - truehd_core bitstream filter - dhav demuxer - PCM-DVD encoder +- removed libndi-newtek version 4.1: diff --git a/configure b/configure index 2af6c0d..4e86a3b 100755 --- a/configure +++ b/configure @@ -297,7 +297,6 @@ External library support: --enable-lv2 enable LV2 audio filtering [no] --disable-lzma disable lzma [autodetect] --enable-decklink enable Blackmagic DeckLink I/O support [no] - --enable-libndi_newtek enable Newteck NDI I/O support [no] --enable-mbedtls enable mbedTLS, needed for https support if openssl, gnutls or libtls is not used [no] --enable-mediacodec enable Android MediaCodec support [no] @@ -1675,7 +1674,6 @@ EXTERNAL_LIBRARY_GPL_LIST=" EXTERNAL_LIBRARY_NONFREE_LIST=" decklink - libndi_newtek libfdk_aac openssl libtls @@ -3256,10 +3254,6 @@ decklink_indev_extralibs="-lstdc++" decklink_outdev_deps="decklink threads" decklink_outdev_suggest="libklvanc" decklink_outdev_extralibs="-lstdc++" -libndi_newtek_indev_deps="libndi_newtek" -libndi_newtek_indev_extralibs="-lndi" -libndi_newtek_outdev_deps="libndi_newtek" -libndi_newtek_outdev_extralibs="-lndi" dshow_indev_deps="IBaseFilter" dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi" fbdev_indev_deps="linux_fb_h" @@ -6064,7 +6058,6 @@ enabled cuda_sdk && require cuda_sdk cuda.h cuCtxCreate -lcuda enabled chromaprint && require chromaprint chromaprint.h chromaprint_get_version -lchromaprint enabled decklink && { require_headers DeckLinkAPI.h && { test_cpp_condition DeckLinkAPIVersion.h "BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a090500" || die "ERROR: Decklink API version must be >= 10.9.5."; } } -enabled libndi_newtek && require_headers Processing.NDI.Lib.h enabled frei0r && require_headers frei0r.h enabled gmp && require gmp gmp.h mpz_export -lgmp enabled gnutls && require_pkg_config gnutls gnutls gnutls/gnutls.h gnutls_global_init diff --git a/libavdevice/Makefile b/libavdevice/Makefile index f11a6f2..5a907aa 100644 --- a/libavdevice/Makefile +++ b/libavdevice/Makefile @@ -20,8 +20,6 @@ OBJS-$(CONFIG_BKTR_INDEV) += bktr.o OBJS-$(CONFIG_CACA_OUTDEV) += caca.o OBJS-$(CONFIG_DECKLINK_OUTDEV) += decklink_enc.o decklink_enc_c.o decklink_common.o OBJS-$(CONFIG_DECKLINK_INDEV) += decklink_dec.o decklink_dec_c.o decklink_common.o -OBJS-$(CONFIG_LIBNDI_NEWTEK_OUTDEV) += libndi_newtek_enc.o -OBJS-$(CONFIG_LIBNDI_NEWTEK_INDEV) += libndi_newtek_dec.o OBJS-$(CONFIG_DSHOW_INDEV) += dshow_crossbar.o dshow.o dshow_enummediatypes.o \ dshow_enumpins.o dshow_filter.o \ dshow_pin.o dshow_common.o diff --git a/libavdevice/libndi_newtek_common.h b/libavdevice/libndi_newtek_common.h deleted file mode 100644 index 8990317..0000000 --- a/libavdevice/libndi_newtek_common.h +++ /dev/null @@ -1,30 +0,0 @@ -/* - * NewTek NDI common code - * Copyright (c) 2017 Maksym Veremeyenko - * - * This file is part of FFmpeg. - * - * FFmpeg is free software; you can redistribute it and/or - * modify it under the terms of the GNU Lesser General Public - * License as published by the Free Software Foundation; either - * version 2.1 of the License, or (at your option) any later version. - * - * FFmpeg is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * Lesser General Public License for more details. - * - * You should have received a copy of the GNU Lesser General Public - * License along with FFmpeg; if not, write to the Free Software - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA - */ - -#ifndef AVDEVICE_LIBNDI_NEWTEK_COMMON_H -#define AVDEVICE_LIBNDI_NEWTEK_COMMON_H - -#include <Processing.NDI.Lib.h> - -#define NDI_TIME_BASE 10000000 -#define NDI_TIME_BASE_Q (AVRational){1, NDI_TIME_BASE} - -#endif diff --git a/libavdevice/libndi_newtek_dec.c b/libavdevice/libndi_newtek_dec.c deleted file mode 100644 index d2d5648..0000000 --- a/libavdevice/libndi_newtek_dec.c +++ /dev/null @@ -1,342 +0,0 @@ -/* - * Newtek NDI input - * Copyright (c) 2017 Maksym Veremeyenko - * - * This file is part of FFmpeg. - * - * FFmpeg is free software; you can redistribute it and/or - * modify it under the terms of the GNU Lesser General Public - * License as published by the Free Software Foundation; either - * version 2.1 of the License, or (at your option) any later version. - * - * FFmpeg is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * Lesser General Public License for more details. - * - * You should have received a copy of the GNU Lesser General Public - * License along with FFmpeg; if not, write to the Free Software - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA - */ - -#include "libavformat/avformat.h" -#include "libavformat/internal.h" -#include "libavutil/opt.h" -#include "libavutil/imgutils.h" - -#include "libndi_newtek_common.h" - -struct NDIContext { - const AVClass *cclass; - - /* Options */ - int find_sources; - int64_t wait_sources; - int allow_video_fields; - char *extra_ips; - - /* Runtime */ - NDIlib_recv_create_t *recv; - NDIlib_find_instance_t ndi_find; - - /* Streams */ - AVStream *video_st, *audio_st; -}; - -static int ndi_set_video_packet(AVFormatContext *avctx, NDIlib_video_frame_t *v, AVPacket *pkt) -{ - int ret; - struct NDIContext *ctx = avctx->priv_data; - - ret = av_new_packet(pkt, v->yres * v->line_stride_in_bytes); - if (ret < 0) - return ret; - - pkt->dts = pkt->pts = av_rescale_q(v->timecode, NDI_TIME_BASE_Q, ctx->video_st->time_base); - pkt->duration = av_rescale_q(1, (AVRational){v->frame_rate_D, v->frame_rate_N}, ctx->video_st->time_base); - - av_log(avctx, AV_LOG_DEBUG, "%s: pkt->dts = pkt->pts = %"PRId64", duration=%"PRId64", timecode=%"PRId64"\n", - __func__, pkt->dts, pkt->duration, v->timecode); - - pkt->flags |= AV_PKT_FLAG_KEY; - pkt->stream_index = ctx->video_st->index; - - memcpy(pkt->data, v->p_data, pkt->size); - - return 0; -} - -static int ndi_set_audio_packet(AVFormatContext *avctx, NDIlib_audio_frame_t *a, AVPacket *pkt) -{ - int ret; - struct NDIContext *ctx = avctx->priv_data; - - NDIlib_audio_frame_interleaved_16s_t dst; - - ret = av_new_packet(pkt, 2 * a->no_samples * a->no_channels); - if (ret < 0) - return ret; - - pkt->dts = pkt->pts = av_rescale_q(a->timecode, NDI_TIME_BASE_Q, ctx->audio_st->time_base); - pkt->duration = av_rescale_q(1, (AVRational){a->no_samples, a->sample_rate}, ctx->audio_st->time_base); - - av_log(avctx, AV_LOG_DEBUG, "%s: pkt->dts = pkt->pts = %"PRId64", duration=%"PRId64", timecode=%"PRId64"\n", - __func__, pkt->dts, pkt->duration, a->timecode); - - pkt->flags |= AV_PKT_FLAG_KEY; - pkt->stream_index = ctx->audio_st->index; - - dst.reference_level = 0; - dst.p_data = (short *)pkt->data; - NDIlib_util_audio_to_interleaved_16s(a, &dst); - - return 0; -} - -static int ndi_find_sources(AVFormatContext *avctx, const char *name, NDIlib_source_t *source_to_connect_to) -{ - int j = AVERROR(ENODEV); - unsigned int n, i; - struct NDIContext *ctx = avctx->priv_data; - const NDIlib_source_t *ndi_srcs = NULL; - const NDIlib_find_create_t find_create_desc = { .show_local_sources = true, - .p_groups = NULL, .p_extra_ips = ctx->extra_ips }; - - if (!ctx->ndi_find) - ctx->ndi_find = NDIlib_find_create2(&find_create_desc); - if (!ctx->ndi_find) { - av_log(avctx, AV_LOG_ERROR, "NDIlib_find_create failed.\n"); - return AVERROR(EIO); - } - - while (1) - { - int f, t = ctx->wait_sources / 1000; - av_log(avctx, AV_LOG_DEBUG, "Waiting for sources %d miliseconds\n", t); - f = NDIlib_find_wait_for_sources(ctx->ndi_find, t); - av_log(avctx, AV_LOG_DEBUG, "NDIlib_find_wait_for_sources returns %d\n", f); - if (!f) - break; - }; - - ndi_srcs = NDIlib_find_get_current_sources(ctx->ndi_find, &n); - - if (ctx->find_sources) - av_log(avctx, AV_LOG_INFO, "Found %d NDI sources:\n", n); - - for (i = 0; i < n; i++) { - if (ctx->find_sources) - av_log(avctx, AV_LOG_INFO, "\t'%s'\t'%s'\n", ndi_srcs[i].p_ndi_name, ndi_srcs[i].p_ip_address); - - if (!strcmp(name, ndi_srcs[i].p_ndi_name)) { - *source_to_connect_to = ndi_srcs[i]; - j = i; - } - } - - return j; -} - -static int ndi_read_header(AVFormatContext *avctx) -{ - int ret; - NDIlib_recv_create_t recv_create_desc; - const NDIlib_tally_t tally_state = { .on_program = true, .on_preview = false }; - struct NDIContext *ctx = avctx->priv_data; - - if (!NDIlib_initialize()) { - av_log(avctx, AV_LOG_ERROR, "NDIlib_initialize failed.\n"); - return AVERROR_EXTERNAL; - } - - /* Find available sources. */ - ret = ndi_find_sources(avctx, avctx->url, &recv_create_desc.source_to_connect_to); - if (ctx->find_sources) { - return AVERROR_EXIT; - } - if (ret < 0) - return ret; - - /* Create receiver description */ - recv_create_desc.color_format = NDIlib_recv_color_format_e_UYVY_RGBA; - recv_create_desc.bandwidth = NDIlib_recv_bandwidth_highest; - recv_create_desc.allow_video_fields = ctx->allow_video_fields; - - /* Create the receiver */ - ctx->recv = NDIlib_recv_create(&recv_create_desc); - if (!ctx->recv) { - av_log(avctx, AV_LOG_ERROR, "NDIlib_recv_create2 failed.\n"); - return AVERROR(EIO); - } - - /* Set tally */ - NDIlib_recv_set_tally(ctx->recv, &tally_state); - - avctx->ctx_flags |= AVFMTCTX_NOHEADER; - - return 0; -} - -static int ndi_create_video_stream(AVFormatContext *avctx, NDIlib_video_frame_t *v) -{ - AVStream *st; - AVRational tmp; - struct NDIContext *ctx = avctx->priv_data; - - st = avformat_new_stream(avctx, NULL); - if (!st) { - av_log(avctx, AV_LOG_ERROR, "Cannot add video stream\n"); - return AVERROR(ENOMEM); - } - - st->time_base = NDI_TIME_BASE_Q; - st->r_frame_rate = av_make_q(v->frame_rate_N, v->frame_rate_D); - - tmp = av_mul_q(av_d2q(v->picture_aspect_ratio, INT_MAX), (AVRational){v->yres, v->xres}); - av_reduce(&st->sample_aspect_ratio.num, &st->sample_aspect_ratio.den, tmp.num, tmp.den, 1000); - st->codecpar->sample_aspect_ratio = st->sample_aspect_ratio; - - st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO; - st->codecpar->width = v->xres; - st->codecpar->height = v->yres; - st->codecpar->codec_id = AV_CODEC_ID_RAWVIDEO; - st->codecpar->bit_rate = av_rescale(v->xres * v->yres * 16, v->frame_rate_N, v->frame_rate_D); - st->codecpar->field_order = v->frame_format_type == NDIlib_frame_format_type_progressive - ? AV_FIELD_PROGRESSIVE : AV_FIELD_TT; - - if (NDIlib_FourCC_type_UYVY == v->FourCC || NDIlib_FourCC_type_UYVA == v->FourCC) { - st->codecpar->format = AV_PIX_FMT_UYVY422; - st->codecpar->codec_tag = MKTAG('U', 'Y', 'V', 'Y'); - if (NDIlib_FourCC_type_UYVA == v->FourCC) - av_log(avctx, AV_LOG_WARNING, "Alpha channel ignored\n"); - } else if (NDIlib_FourCC_type_BGRA == v->FourCC) { - st->codecpar->format = AV_PIX_FMT_BGRA; - st->codecpar->codec_tag = MKTAG('B', 'G', 'R', 'A'); - } else if (NDIlib_FourCC_type_BGRX == v->FourCC) { - st->codecpar->format = AV_PIX_FMT_BGR0; - st->codecpar->codec_tag = MKTAG('B', 'G', 'R', '0'); - } else if (NDIlib_FourCC_type_RGBA == v->FourCC) { - st->codecpar->format = AV_PIX_FMT_RGBA; - st->codecpar->codec_tag = MKTAG('R', 'G', 'B', 'A'); - } else if (NDIlib_FourCC_type_RGBX == v->FourCC) { - st->codecpar->format = AV_PIX_FMT_RGB0; - st->codecpar->codec_tag = MKTAG('R', 'G', 'B', '0'); - } else { - av_log(avctx, AV_LOG_ERROR, "Unsupported video stream format, v->FourCC=%d\n", v->FourCC); - return AVERROR(EINVAL); - } - - avpriv_set_pts_info(st, 64, 1, NDI_TIME_BASE); - - ctx->video_st = st; - - return 0; -} - -static int ndi_create_audio_stream(AVFormatContext *avctx, NDIlib_audio_frame_t *a) -{ - AVStream *st; - struct NDIContext *ctx = avctx->priv_data; - - st = avformat_new_stream(avctx, NULL); - if (!st) { - av_log(avctx, AV_LOG_ERROR, "Cannot add audio stream\n"); - return AVERROR(ENOMEM); - } - - st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO; - st->codecpar->codec_id = AV_CODEC_ID_PCM_S16LE; - st->codecpar->sample_rate = a->sample_rate; - st->codecpar->channels = a->no_channels; - - avpriv_set_pts_info(st, 64, 1, NDI_TIME_BASE); - - ctx->audio_st = st; - - return 0; -} - -static int ndi_read_packet(AVFormatContext *avctx, AVPacket *pkt) -{ - int ret = 0; - struct NDIContext *ctx = avctx->priv_data; - - while (!ret) { - NDIlib_video_frame_t v; - NDIlib_audio_frame_t a; - NDIlib_metadata_frame_t m; - NDIlib_frame_type_e t; - - av_log(avctx, AV_LOG_DEBUG, "NDIlib_recv_capture...\n"); - t = NDIlib_recv_capture(ctx->recv, &v, &a, &m, 40); - av_log(avctx, AV_LOG_DEBUG, "NDIlib_recv_capture=%d\n", t); - - if (t == NDIlib_frame_type_video) { - if (!ctx->video_st) - ret = ndi_create_video_stream(avctx, &v); - if (!ret) - ret = ndi_set_video_packet(avctx, &v, pkt); - NDIlib_recv_free_video(ctx->recv, &v); - break; - } - else if (t == NDIlib_frame_type_audio) { - if (!ctx->audio_st) - ret = ndi_create_audio_stream(avctx, &a); - if (!ret) - ret = ndi_set_audio_packet(avctx, &a, pkt); - NDIlib_recv_free_audio(ctx->recv, &a); - break; - } - else if (t == NDIlib_frame_type_metadata) - NDIlib_recv_free_metadata(ctx->recv, &m); - else if (t == NDIlib_frame_type_error){ - av_log(avctx, AV_LOG_ERROR, "NDIlib_recv_capture failed with error\n"); - ret = AVERROR(EIO); - } - }; - - return ret; -} - -static int ndi_read_close(AVFormatContext *avctx) -{ - struct NDIContext *ctx = (struct NDIContext *)avctx->priv_data; - - if (ctx->recv) - NDIlib_recv_destroy(ctx->recv); - - if (ctx->ndi_find) - NDIlib_find_destroy(ctx->ndi_find); - - return 0; -} - -#define OFFSET(x) offsetof(struct NDIContext, x) -#define DEC AV_OPT_FLAG_DECODING_PARAM - -static const AVOption options[] = { - { "find_sources", "Find available sources" , OFFSET(find_sources), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, DEC }, - { "wait_sources", "Time to wait until the number of online sources have changed" , OFFSET(wait_sources), AV_OPT_TYPE_DURATION, { .i64 = 1000000 }, 100000, 20000000, DEC }, - { "allow_video_fields", "When this flag is FALSE, all video that you receive will be progressive" , OFFSET(allow_video_fields), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, DEC }, - { "extra_ips", "List of comma separated ip addresses to scan for remote sources", OFFSET(extra_ips), AV_OPT_TYPE_STRING, {.str = NULL }, 0, 0, DEC }, - { NULL }, -}; - -static const AVClass libndi_newtek_demuxer_class = { - .class_name = "NDI demuxer", - .item_name = av_default_item_name, - .option = options, - .version = LIBAVUTIL_VERSION_INT, - .category = AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT, -}; - -AVInputFormat ff_libndi_newtek_demuxer = { - .name = "libndi_newtek", - .long_name = NULL_IF_CONFIG_SMALL("Network Device Interface (NDI) input using NewTek library"), - .flags = AVFMT_NOFILE, - .priv_class = &libndi_newtek_demuxer_class, - .priv_data_size = sizeof(struct NDIContext), - .read_header = ndi_read_header, - .read_packet = ndi_read_packet, - .read_close = ndi_read_close, -}; diff --git a/libavdevice/libndi_newtek_enc.c b/libavdevice/libndi_newtek_enc.c deleted file mode 100644 index f3603f5..0000000 --- a/libavdevice/libndi_newtek_enc.c +++ /dev/null @@ -1,299 +0,0 @@ -/* - * NewTek NDI output - * Copyright (c) 2017 Maksym Veremeyenko - * - * This file is part of FFmpeg. - * - * FFmpeg is free software; you can redistribute it and/or - * modify it under the terms of the GNU Lesser General Public - * License as published by the Free Software Foundation; either - * version 2.1 of the License, or (at your option) any later version. - * - * FFmpeg is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * Lesser General Public License for more details. - * - * You should have received a copy of the GNU Lesser General Public - * License along with FFmpeg; if not, write to the Free Software - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA - */ - -#include "libavformat/avformat.h" -#include "libavformat/internal.h" -#include "libavutil/opt.h" -#include "libavutil/imgutils.h" - -#include "libndi_newtek_common.h" - -struct NDIContext { - const AVClass *cclass; - - /* Options */ - int reference_level; - int clock_video, clock_audio; - - NDIlib_video_frame_t *video; - NDIlib_audio_frame_interleaved_16s_t *audio; - NDIlib_send_instance_t ndi_send; - AVFrame *last_avframe; -}; - -static int ndi_write_trailer(AVFormatContext *avctx) -{ - struct NDIContext *ctx = avctx->priv_data; - - if (ctx->ndi_send) { - NDIlib_send_destroy(ctx->ndi_send); - av_frame_free(&ctx->last_avframe); - } - - av_freep(&ctx->video); - av_freep(&ctx->audio); - - return 0; -} - -static int ndi_write_video_packet(AVFormatContext *avctx, AVStream *st, AVPacket *pkt) -{ - struct NDIContext *ctx = avctx->priv_data; - AVFrame *avframe, *tmp = (AVFrame *)pkt->data; - - if (tmp->format != AV_PIX_FMT_UYVY422 && tmp->format != AV_PIX_FMT_BGRA && - tmp->format != AV_PIX_FMT_BGR0 && tmp->format != AV_PIX_FMT_RGBA && - tmp->format != AV_PIX_FMT_RGB0) { - av_log(avctx, AV_LOG_ERROR, "Got a frame with invalid pixel format.\n"); - return AVERROR(EINVAL); - } - - if (tmp->linesize[0] < 0) { - av_log(avctx, AV_LOG_ERROR, "Got a frame with negative linesize.\n"); - return AVERROR(EINVAL); - } - - if (tmp->width != ctx->video->xres || - tmp->height != ctx->video->yres) { - av_log(avctx, AV_LOG_ERROR, "Got a frame with invalid dimension.\n"); - av_log(avctx, AV_LOG_ERROR, "tmp->width=%d, tmp->height=%d, ctx->video->xres=%d, ctx->video->yres=%d\n", - tmp->width, tmp->height, ctx->video->xres, ctx->video->yres); - return AVERROR(EINVAL); - } - - avframe = av_frame_clone(tmp); - if (!avframe) - return AVERROR(ENOMEM); - - ctx->video->timecode = av_rescale_q(pkt->pts, st->time_base, NDI_TIME_BASE_Q); - - ctx->video->line_stride_in_bytes = avframe->linesize[0]; - ctx->video->p_data = (void *)(avframe->data[0]); - - av_log(avctx, AV_LOG_DEBUG, "%s: pkt->pts=%"PRId64", timecode=%"PRId64", st->time_base=%d/%d\n", - __func__, pkt->pts, ctx->video->timecode, st->time_base.num, st->time_base.den); - - /* asynchronous for one frame, but will block if a second frame - is given before the first one has been sent */ - NDIlib_send_send_video_async(ctx->ndi_send, ctx->video); - - av_frame_free(&ctx->last_avframe); - ctx->last_avframe = avframe; - - return 0; -} - -static int ndi_write_audio_packet(AVFormatContext *avctx, AVStream *st, AVPacket *pkt) -{ - struct NDIContext *ctx = avctx->priv_data; - - ctx->audio->p_data = (short *)pkt->data; - ctx->audio->timecode = av_rescale_q(pkt->pts, st->time_base, NDI_TIME_BASE_Q); - ctx->audio->no_samples = pkt->size / (ctx->audio->no_channels << 1); - - av_log(avctx, AV_LOG_DEBUG, "%s: pkt->pts=%"PRId64", timecode=%"PRId64", st->time_base=%d/%d\n", - __func__, pkt->pts, ctx->audio->timecode, st->time_base.num, st->time_base.den); - - NDIlib_util_send_send_audio_interleaved_16s(ctx->ndi_send, ctx->audio); - - return 0; -} - -static int ndi_write_packet(AVFormatContext *avctx, AVPacket *pkt) -{ - AVStream *st = avctx->streams[pkt->stream_index]; - - if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) - return ndi_write_video_packet(avctx, st, pkt); - else if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) - return ndi_write_audio_packet(avctx, st, pkt); - - return AVERROR_BUG; -} - -static int ndi_setup_audio(AVFormatContext *avctx, AVStream *st) -{ - struct NDIContext *ctx = avctx->priv_data; - AVCodecParameters *c = st->codecpar; - - if (ctx->audio) { - av_log(avctx, AV_LOG_ERROR, "Only one audio stream is supported!\n"); - return AVERROR(EINVAL); - } - - ctx->audio = av_mallocz(sizeof(NDIlib_audio_frame_interleaved_16s_t)); - if (!ctx->audio) - return AVERROR(ENOMEM); - - ctx->audio->sample_rate = c->sample_rate; - ctx->audio->no_channels = c->channels; - ctx->audio->reference_level = ctx->reference_level; - - avpriv_set_pts_info(st, 64, 1, NDI_TIME_BASE); - - return 0; -} - -static int ndi_setup_video(AVFormatContext *avctx, AVStream *st) -{ - struct NDIContext *ctx = avctx->priv_data; - AVCodecParameters *c = st->codecpar; - - if (ctx->video) { - av_log(avctx, AV_LOG_ERROR, "Only one video stream is supported!\n"); - return AVERROR(EINVAL); - } - - if (c->codec_id != AV_CODEC_ID_WRAPPED_AVFRAME) { - av_log(avctx, AV_LOG_ERROR, "Unsupported codec format!" - " Only AV_CODEC_ID_WRAPPED_AVFRAME is supported (-vcodec wrapped_avframe).\n"); - return AVERROR(EINVAL); - } - - if (c->format != AV_PIX_FMT_UYVY422 && c->format != AV_PIX_FMT_BGRA && - c->format != AV_PIX_FMT_BGR0 && c->format != AV_PIX_FMT_RGBA && - c->format != AV_PIX_FMT_RGB0) { - av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format!" - " Only AV_PIX_FMT_UYVY422, AV_PIX_FMT_BGRA, AV_PIX_FMT_BGR0," - " AV_PIX_FMT_RGBA, AV_PIX_FMT_RGB0 is supported.\n"); - return AVERROR(EINVAL); - } - - if (c->field_order == AV_FIELD_BB || c->field_order == AV_FIELD_BT) { - av_log(avctx, AV_LOG_ERROR, "Lower field-first disallowed"); - return AVERROR(EINVAL); - } - - ctx->video = av_mallocz(sizeof(NDIlib_video_frame_t)); - if (!ctx->video) - return AVERROR(ENOMEM); - - switch(c->format) { - case AV_PIX_FMT_UYVY422: - ctx->video->FourCC = NDIlib_FourCC_type_UYVY; - break; - case AV_PIX_FMT_BGRA: - ctx->video->FourCC = NDIlib_FourCC_type_BGRA; - break; - case AV_PIX_FMT_BGR0: - ctx->video->FourCC = NDIlib_FourCC_type_BGRX; - break; - case AV_PIX_FMT_RGBA: - ctx->video->FourCC = NDIlib_FourCC_type_RGBA; - break; - case AV_PIX_FMT_RGB0: - ctx->video->FourCC = NDIlib_FourCC_type_RGBX; - break; - } - - ctx->video->xres = c->width; - ctx->video->yres = c->height; - ctx->video->frame_rate_N = st->avg_frame_rate.num; - ctx->video->frame_rate_D = st->avg_frame_rate.den; - ctx->video->frame_format_type = c->field_order == AV_FIELD_PROGRESSIVE - ? NDIlib_frame_format_type_progressive - : NDIlib_frame_format_type_interleaved; - - if (st->sample_aspect_ratio.num) { - AVRational display_aspect_ratio; - av_reduce(&display_aspect_ratio.num, &display_aspect_ratio.den, - st->codecpar->width * (int64_t)st->sample_aspect_ratio.num, - st->codecpar->height * (int64_t)st->sample_aspect_ratio.den, - 1024 * 1024); - ctx->video->picture_aspect_ratio = av_q2d(display_aspect_ratio); - } - else - ctx->video->picture_aspect_ratio = (double)st->codecpar->width/st->codecpar->height; - - avpriv_set_pts_info(st, 64, 1, NDI_TIME_BASE); - - return 0; -} - -static int ndi_write_header(AVFormatContext *avctx) -{ - int ret = 0; - unsigned int n; - struct NDIContext *ctx = avctx->priv_data; - const NDIlib_send_create_t ndi_send_desc = { .p_ndi_name = avctx->url, - .p_groups = NULL, .clock_video = ctx->clock_video, .clock_audio = ctx->clock_audio }; - - if (!NDIlib_initialize()) { - av_log(avctx, AV_LOG_ERROR, "NDIlib_initialize failed.\n"); - return AVERROR_EXTERNAL; - } - - /* check if streams compatible */ - for (n = 0; n < avctx->nb_streams; n++) { - AVStream *st = avctx->streams[n]; - AVCodecParameters *c = st->codecpar; - if (c->codec_type == AVMEDIA_TYPE_AUDIO) { - if ((ret = ndi_setup_audio(avctx, st))) - goto error; - } else if (c->codec_type == AVMEDIA_TYPE_VIDEO) { - if ((ret = ndi_setup_video(avctx, st))) - goto error; - } else { - av_log(avctx, AV_LOG_ERROR, "Unsupported stream type.\n"); - ret = AVERROR(EINVAL); - goto error; - } - } - - ctx->ndi_send = NDIlib_send_create(&ndi_send_desc); - if (!ctx->ndi_send) { - av_log(avctx, AV_LOG_ERROR, "Failed to create NDI output %s\n", avctx->url); - ret = AVERROR_EXTERNAL; - } - -error: - return ret; -} - -#define OFFSET(x) offsetof(struct NDIContext, x) -static const AVOption options[] = { - { "reference_level", "The audio reference level in dB" , OFFSET(reference_level), AV_OPT_TYPE_INT, { .i64 = 0 }, -20, 20, AV_OPT_FLAG_ENCODING_PARAM | AV_OPT_FLAG_AUDIO_PARAM}, - { "clock_video", "These specify whether video 'clock' themselves" , OFFSET(clock_video), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, AV_OPT_FLAG_ENCODING_PARAM | AV_OPT_FLAG_VIDEO_PARAM }, - { "clock_audio", "These specify whether audio 'clock' themselves" , OFFSET(clock_audio), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, AV_OPT_FLAG_ENCODING_PARAM | AV_OPT_FLAG_AUDIO_PARAM }, - { NULL }, -}; - -static const AVClass libndi_newtek_muxer_class = { - .class_name = "NDI muxer", - .item_name = av_default_item_name, - .option = options, - .version = LIBAVUTIL_VERSION_INT, - .category = AV_CLASS_CATEGORY_DEVICE_VIDEO_OUTPUT, -}; - -AVOutputFormat ff_libndi_newtek_muxer = { - .name = "libndi_newtek", - .long_name = NULL_IF_CONFIG_SMALL("Network Device Interface (NDI) output using NewTek library"), - .audio_codec = AV_CODEC_ID_PCM_S16LE, - .video_codec = AV_CODEC_ID_WRAPPED_AVFRAME, - .subtitle_codec = AV_CODEC_ID_NONE, - .flags = AVFMT_NOFILE, - .priv_class = &libndi_newtek_muxer_class, - .priv_data_size = sizeof(struct NDIContext), - .write_header = ndi_write_header, - .write_packet = ndi_write_packet, - .write_trailer = ndi_write_trailer, -}; diff --git a/libavdevice/version.h b/libavdevice/version.h index e6ae2c4..dc82519 100644 --- a/libavdevice/version.h +++ b/libavdevice/version.h @@ -28,8 +28,8 @@ #include "libavutil/version.h" #define LIBAVDEVICE_VERSION_MAJOR 58 -#define LIBAVDEVICE_VERSION_MINOR 6 -#define LIBAVDEVICE_VERSION_MICRO 101 +#define LIBAVDEVICE_VERSION_MINOR 7 +#define LIBAVDEVICE_VERSION_MICRO 100 #define LIBAVDEVICE_VERSION_INT AV_VERSION_INT(LIBAVDEVICE_VERSION_MAJOR, \ LIBAVDEVICE_VERSION_MINOR, \ -- 1.7.10.4