diff mbox

[FFmpeg-devel] lavd: Remove libndi newtek

Message ID CAB0OVGpkpyFzmkuC+kO3-Er3iNYH9hpO4zDTQZbRpEyFu=fjuQ@mail.gmail.com
State Accepted
Headers show

Commit Message

Carl Eugen Hoyos Dec. 3, 2018, 4:05 p.m. UTC
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

Comments

Dennis Mungai Dec. 3, 2018, 4:13 p.m. UTC | #1
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
>
Gyan Dec. 3, 2018, 4:16 p.m. UTC | #2
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
Carl Eugen Hoyos Dec. 3, 2018, 4:19 p.m. UTC | #3
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
Gyan Dec. 3, 2018, 4:23 p.m. UTC | #4
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
Carl Eugen Hoyos Dec. 3, 2018, 4:24 p.m. UTC | #5
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
Kyle Schwarz Dec. 3, 2018, 4:26 p.m. UTC | #6
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.
Dennis Mungai Dec. 3, 2018, 4:37 p.m. UTC | #7
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
>
Nicolas George Dec. 3, 2018, 4:38 p.m. UTC | #8
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,
Dennis Mungai Dec. 3, 2018, 4:39 p.m. UTC | #9
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
>
Nicolas George Dec. 3, 2018, 4:41 p.m. UTC | #10
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,
Timo Rothenpieler Dec. 3, 2018, 6:12 p.m. UTC | #11
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.
Carl Eugen Hoyos Dec. 3, 2018, 6:16 p.m. UTC | #12
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
Jan Ekström Dec. 3, 2018, 6:45 p.m. UTC | #13
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
Paul B Mahol Dec. 3, 2018, 6:48 p.m. UTC | #14
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.
Jan Ekström Dec. 3, 2018, 6:54 p.m. UTC | #15
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
Ali KIZIL Dec. 3, 2018, 6:55 p.m. UTC | #16
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.
Carl Eugen Hoyos Dec. 3, 2018, 8:40 p.m. UTC | #17
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
Nicolas George Dec. 3, 2018, 8:51 p.m. UTC | #18
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,
Ali KIZIL Dec. 3, 2018, 9 p.m. UTC | #19
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.
Paul B Mahol Dec. 3, 2018, 9:01 p.m. UTC | #20
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?
Nicolas George Dec. 3, 2018, 9:05 p.m. UTC | #21
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,
Carl Eugen Hoyos Dec. 3, 2018, 9:07 p.m. UTC | #22
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
Jan Ekström Dec. 3, 2018, 9:07 p.m. UTC | #23
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
Ali KIZIL Dec. 3, 2018, 9:19 p.m. UTC | #24
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.
Marton Balint Dec. 3, 2018, 9:28 p.m. UTC | #25
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
Jean-Baptiste Kempf Dec. 3, 2018, 9:54 p.m. UTC | #26
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,
Jean-Baptiste Kempf Dec. 3, 2018, 9:59 p.m. UTC | #27
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)
Jean-Baptiste Kempf Dec. 3, 2018, 10 p.m. UTC | #28
> Again: What message would this send to future license violators?

A bad one.

I would remove this.
Marton Balint Dec. 3, 2018, 10:14 p.m. UTC | #29
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
Ali KIZIL Dec. 3, 2018, 10:22 p.m. UTC | #30
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.

>
>
Jean-Baptiste Kempf Dec. 3, 2018, 10:34 p.m. UTC | #31
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.
Martin Vignali Dec. 4, 2018, 2 p.m. UTC | #32
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
Carl Eugen Hoyos Dec. 4, 2018, 2:28 p.m. UTC | #33
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
Jean-Baptiste Kempf Dec. 4, 2018, 3:12 p.m. UTC | #34
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?
Martin Vignali Dec. 4, 2018, 9:50 p.m. UTC | #35
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
Ronald S. Bultje Dec. 4, 2018, 10:36 p.m. UTC | #36
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
Nicolas George Dec. 5, 2018, 1:55 p.m. UTC | #37
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,
Jean-Baptiste Kempf Dec. 5, 2018, 4:25 p.m. UTC | #38
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.
Carl Eugen Hoyos Dec. 10, 2018, 2:11 a.m. UTC | #39
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
Gyan Doshi Dec. 10, 2018, 8:46 a.m. UTC | #40
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
Ali KIZIL Dec. 10, 2018, 9:14 a.m. UTC | #41
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
Carl Eugen Hoyos Dec. 10, 2018, 12:25 p.m. UTC | #42
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
diff mbox

Patch

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