[Ffmpeg-devel-irc] ffmpeg-devel.log.20190506

[burek]

[00:00:01 CEST] <BtbN> The library probably wasn't the "core" of their business though
[00:00:16 CEST] <cehoyos> I still wonder why nobody claimed this at a time when it could be verified...
[00:00:43 CEST] <cehoyos> They claimed it several days later when they were still distributing the offending binary.
[00:01:11 CEST] <BtbN> I checked it on the same day myself. The new micro release of the SDK came entirely without ffmpeg binaries.
[00:01:45 CEST] <cehoyos> Why didn't you inform us?
[00:02:17 CEST] <BtbN> It was mentioned on the ML several times...
[00:02:20 CEST] <cehoyos> Anyway: Thank your for letting me know that "no further action" is indeed an alternative, I honestly wasn't aware!"
[00:02:35 CEST] <cehoyos> (Afair, I asked and nobody confirmed this.)
[00:02:49 CEST] <BtbN> Wasn't it even mentioned on trac?
[00:03:07 CEST] <cehoyos> No, it was promised that "all measures to fix the violation will be taken"
[00:03:10 CEST] <cehoyos> lol
[00:04:13 CEST] <BtbN> My favourite course of action so far that would actually hurt Newtek and that I'd be very okay with is to come up with a feature equivalent open solution for the problem NDI solves.
[00:04:28 CEST] <cehoyos> So after we all agreed that we should not take any action wrt copyright violators: Shouldn't we try to change the license to MIT or public domain?
[00:04:35 CEST] <BtbN> Doesn't even need much, just someone to put a few things together.
[00:05:09 CEST] <BtbN> I personally would very welcome MIT or 3-Clause-BSD, avoids a lot of chaos like this.
[00:05:16 CEST] <BtbN> But I doubt many will agree there.
[00:05:43 CEST] <cehoyos> (It is not an option since we cannot ask all contributors: But again, good to know!)
[00:06:51 CEST] <cehoyos> I now understand your argumentation: Please try to understand that some contributors do not agree to such a relicensing and therefore want the current license to be taken seriously.
[00:07:32 CEST] <cehoyos> ... and are actually strongly against it
[00:08:12 CEST] <BtbN> The thing with Newtek is, that it very much feels like a few people have a personal Vendetta to settle there, and it's very hard to find out what's entirely behind it.
[00:08:27 CEST] <BtbN> And/Or just a generall strong dislike against commercial users.
[00:09:06 CEST] <BtbN> I stopped replying on the matter on the ML because it feels to me like a rational argument about it is impossible.
[00:09:32 CEST] <BradleyS> from what i can tell, what's behind it is not about commerce, it's the repeated violations and threats, acting in bad faith
[00:09:51 CEST] <cehoyos> I wonder what "personal vendetta" means here: We (the FFmpeg project) has endorsed their proprietary software. The were informed that because their library is proprietary, linked GPL'd ffmpeg binaries cannot be distributed. They distributed it nonetheless, we removed our endorsement.
[00:09:58 CEST] <cehoyos> What exactly is a surprise here?
[00:10:23 CEST] <cehoyos> Since no threat was ever confirmed, I would prefer if it is not used as argument.
[00:10:43 CEST] <BtbN> That this does not actually hurt Newtek, but mainly open source users who now have to deal with 3rd party patches to do their work.
[00:11:46 CEST] <cehoyos> BtbN: But that is exactly the point: I consider is completely irrational that the reaction to a license violation should be "we continue to endorse the violator", until now I even assumed that nobody would suggest this.
[00:11:57 CEST] <cehoyos> That sounds surprising to me...
[00:12:09 CEST] <BtbN> There is a lot of professional (literally) black-box equipment where NDI falls out of. FFmpeg was (and with the patch back in still is) the best way to interface with them.
[00:12:33 CEST] <cehoyos> And this will now - hopefully - change.
[00:12:50 CEST] <BtbN> Nope, it won't unfortunately.
[00:12:55 CEST] <nevcairiel> if anything, they wont stop using NDI, they'll stop using ffmpeg
[00:13:02 CEST] <cehoyos> Who will maintain the patch?
[00:13:10 CEST] <nevcairiel> newtek didnt lose anything, only the users lost something
[00:13:12 CEST] <BtbN> That's exactly the problem of it not being in ffmpeg anymore
[00:13:54 CEST] <cehoyos> So if you all believe that the users need this library so much: Why don't you simply sue?
[00:13:59 CEST] <nevcairiel> nothing prevents newtek from providing the patch and a ffmpeg binary, as long as they dont link to it
[00:14:24 CEST] <cehoyos> They are not allowed to distribute any FFmpeg binaries, no matter if linked to libndi or not.
[00:14:26 CEST] <BtbN> iirc the patch wasn't even from Newtek in any way, but from someone who just wanted to use NDI with FFmpeg?
[00:14:29 CEST] <nevcairiel> or a source p ackage and build scripts anyway
[00:14:38 CEST] <cehoyos> Iirc, this includes the source package.
[00:14:59 CEST] <BtbN> Hm? They can distribute (L)GPL sources all they wan't.
[00:15:01 CEST] <nevcairiel> and anyone is allowed to distribute ffmpeg binaries
[00:15:02 CEST] <cehoyos> No.
[00:15:28 CEST] <nevcairiel> the license explicitly allows it, as long as you obey various rules
[00:15:56 CEST] <BtbN> The code in ffmpeg itself was LGPL, it's only the resulting binary that's nonfree. So they absolutely can distribute that.
[00:15:58 CEST] <cehoyos> (This is the repeated argument of "the GPL is actually not enforceable" - the good thing is that it can be enforced)
[00:16:39 CEST] <cehoyos> No, they have lost the right to distribute FFmpeg when they violated its license terms, I don't think we will reinstate their license before they open-source libndi.
[00:17:25 CEST] <BtbN> That's probably something only a bunch of lawyers can settle, and will vary by country.
[00:17:34 CEST] <cehoyos> I am talking about the US
[00:17:42 CEST] <cehoyos> (in this - rare - case)
[01:26:48 CEST] <hanetzer> what is NDI in this context?
[01:26:55 CEST] Action: hanetzer just read a lotta backlog
[01:35:09 CEST] <iive> hanetzer, some network streaming framework
[01:42:00 CEST] <hanetzer> nice. read #7589 in the meanwhile, what a prick of a company
[01:49:29 CEST] <hanetzer> iive: at least amazon played ball :)
[01:51:00 CEST] <iive> i remember somebody talking about it, how they have known exploits in their blog and how they have threatened some developer doing foss implementation of their ndi... but I cannot find it in my logs or with google.
[01:51:13 CEST] <iive> maybe I remember wrongly...
[02:04:46 CEST] <hanetzer> yeah. that was mentioned in the above bug.
[02:25:45 CEST] <iive> hanetzer, which bug exactly?
[02:30:56 CEST] <hanetzer> iive: 7589, like I said
[02:41:21 CEST] <cone-980> ffmpeg 03James Almer 07master:d88193c2196c: avformat/aacdec: fix demuxing of small frames
[05:25:34 CEST] <cone-980> ffmpeg 03James Almer 07master:fec4212d8e09: avcodec/vp9_raw_reorder: reset state when flushing
[06:14:33 CEST] <l_vv_nf> Is there anything one must do to qualify to speak in the regular #ffmpeg channel? My apologies if this is the wrong place to ask. 
[06:16:57 CEST] <BradleyS> l_vv_nf: it might have registration set
[06:17:06 CEST] <BradleyS> register your nickname with freenode and set a password
[06:19:44 CEST] <l_vv_nf> Thank you so much. 
[10:50:46 CEST] <superware> is there a way to detect whether input is a file or a stream by examining AVFormatContext?
[10:58:01 CEST] <mkver> Do you really want to know whether it is a file? Or is it enough to know whether you can seek? Looking at whether the AVIO_SEEKABLE_NORMAL bit of the AVIOContext's seekable member is set will tell you whether your I/O is seekable like a normal file.
[10:58:34 CEST] <mkver> This is the commonly used check.
[11:04:54 CEST] <superware> mkver: RTSP can seek, but it's still a stream
[11:05:48 CEST] <superware> I need to know this in order to enable/disable my media player adaptive playback buffer
[18:55:47 CEST] <cone-742> ffmpeg 03James Almer 07release/4.0:82e1fb864b37: avformat/aacdec: fix demuxing of small frames
[18:55:47 CEST] <cone-742> ffmpeg 03James Almer 07release/4.1:7211e1ca9367: avformat/aacdec: fix demuxing of small frames
[21:07:51 CEST] <cone-742> ffmpeg 03Paul B Mahol 07master:066864aca830: avfilter/af_rubberband: handle case when no frame is given
[21:10:38 CEST] <cone-742> ffmpeg 03Paul B Mahol 07master:e668260ba948: avfilter/af_rubberband: also do not ignore failures
[22:36:31 CEST] <JEEB> https://devblogs.microsoft.com/commandline/announcing-wsl-2/
[22:36:33 CEST] <JEEB> > Yes, you did just read that heading correctly! We will be shipping a real Linux kernel with Windows that will make full system call compatibility possible.
[22:41:20 CEST] <cehoyos> I had not realized that git clone was slow...
[22:41:39 CEST] <cehoyos> I was too impressed how flawless it worked.
[22:42:01 CEST] <JEEB> yea
[22:42:08 CEST] <JEEB> the binary compat layer they made for android was a good job
[22:42:31 CEST] <JEEB> (they re-used it in WSL)
[22:42:45 CEST] <JEEB> WSL 2 seems to be a VM, which kind of makes it a bit "less fun"
[22:43:32 CEST] <jkqxz> Can't let that evil GPL code infect everything else, y'know.
[23:01:15 CEST] <nevcairiel> Sounds interesting. If it's still as easy to interact with the windows system and the limits are removed, it's only better
[23:13:51 CEST] <jkqxz> On the closed-source software thing, would people be open to a vote-like survey trying to determine what people actually want?
[23:14:56 CEST] <jkqxz> I feel like the problem we have at the moment is the combination of (a) people have significantly different views, and (b) we don't have common terms of reference for people to say what those views actually are (because the GPL terms are so vague).
[23:18:02 CEST] <cehoyos> And I still believe the problem we have at the moment is that not enough people review patches;-(
[23:18:16 CEST] <jkqxz> So I think it would be helpful to make scales of things people might care about - e.g. freedom, API commonality, consumerishness.
[23:18:28 CEST] <jkqxz> (For example, scale for freedom is something like: (1) all components are free software, (2) all but hardware components are free, (3) all software running on the same processor as ffmpeg is free, (4) nothing is free.)
[23:18:30 CEST] <cehoyos> I don't think the GPL is vague, I believe typical proprietary software licenses are vague...
[23:21:03 CEST] <jkqxz> And then we might be able to come up with a definition which people could vote on without arguing about terms.
[23:25:39 CEST] <cehoyos> Perhaps we should tell people first that they vote at least about decklink, likely also about amd and nvidia
[23:25:39 CEST] <jkqxz> cehoyos:  for c in NVENC NVDEC libmfx CUDA DeckLink that-matrox-hardware-thing ; is $c a major component of the operating system as defined by the GPL?
[23:26:06 CEST] <cehoyos> Yes, the FFmpeg developers say that graphic card drivers are part of the operating system.
[23:26:24 CEST] <cehoyos> Nobody claims that the Matrox driver is part of the operating system, the patch was changed accordingly.
[23:26:53 CEST] <cehoyos> The driver for the Matrox encoding card
[23:31:47 CEST] <jkqxz> And how would you precisely define what is different about the two cases?
[23:32:02 CEST] <jkqxz> I think the argument is based on some sort of scale of consumerishness.  As a consumer I can buy an off-the-shelf machine at a (comparatively) reasonable price with an Nvidia graphics card and containing the drivers already (as part of the operating system), while I can't for the Matrox thing.
[23:34:55 CEST] <cehoyos> I am still always surprised about this question: My computer doesn't work in any useful way without its graphic card driver but I would never consider the driver for a rare expensive hardware that I have to buy and specifically install part of the OS
[23:35:06 CEST] <jkqxz> Suppose there is a large patch to the Nvidia code which adds a load of support for things which can only run on the expensive server cards.  Is that still acceptable because it happens to share a (partially at that point) common API with the consumer cards, or should that change the calcaultion because in reality it's really exactly the same case as the Matrox stuff?
[23:35:16 CEST] <cehoyos> And what could be wrong about the argument as you make it?
[23:35:34 CEST] <cehoyos> I believe it already is exactly as you describe it.
[23:35:58 CEST] <cehoyos> But the cases still look completely (as in: not comparable) different to me.
[23:39:48 CEST] <jkqxz> I'm not saying there is anything wrong with this argument; I'm trying to suggest it as a way to make a more precise definition for what the community would find acceptable.
[23:50:10 CEST] <cehoyos> Please add braces around the else for "No VA display found for "
[23:59:31 CEST] <jkqxz> cehoyos:  Sure.  Added to both branches.
[00:00:00 CEST] --- Tue May  7 2019