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

[burek]

[02:50:32 CEST] <cone-381> ffmpeg 03Carl Eugen Hoyos 07master:60df54ebd23e: configure: Do not overwrite src symlink if it already exists.
[02:52:52 CEST] <cone-381> ffmpeg 03fumoboy007 07master:e384f6f2f903: avcodec/h263dec: Fixed VA API, VDPAU, and VideoToolbox hardware acceleration due to missing `hw_configs` property.
[13:31:21 CEST] <cone-418> ffmpeg 03Paul B Mahol 07master:526bc2205b36: avfilter/vf_vibrance: factor some calculations out of loop
[13:31:21 CEST] <cone-418> ffmpeg 03Paul B Mahol 07master:38baaa1617d8: avfilter/vf_vibrance: add alternate option
[16:34:56 CEST] <durandal_1707> how can i dynamically export AVOptions?
[17:31:30 CEST] <cone-418> ffmpeg 03James Almer 07master:fcc01ba36a7a: avcodec/truehd_core: reset state when flushing
[19:57:59 CEST] <cone-418> ffmpeg 03Paul B Mahol 07master:73f234fdf8d0: avfilter/f_interleave: switch to activate
[20:20:58 CEST] <cone-418> ffmpeg 03Marton Balint 07master:15b8f36be17c: avdevice/decklink: fix checking video mode in SDK version 11
[20:20:59 CEST] <cone-418> ffmpeg 03Marton Balint 07master:328a96839d4d: avfilter/vf_freezedetect: fix missing freeze_start when the freeze length is around the detection duration
[20:31:26 CEST] <cone-418> ffmpeg 03Carl Eugen Hoyos 07master:8cf5f948f24a: lavf/rpl: Don't be case-sensitive detecting codecs.
[20:36:06 CEST] <cone-418> ffmpeg 03ManojGuptaBonda 07master:d617d54efa14: avutil/hwcontext_vdpau: Map 444 pix fmts to new VdpYCbCr types
[20:36:07 CEST] <cone-418> ffmpeg 03ManojGuptaBonda 07master:fc8fb88f10ef: avcodec/vdpau_hevc: Pass sps and pps range extension flags to VDPAU
[20:36:08 CEST] <cone-418> ffmpeg 03ManojGuptaBonda 07master:d7d82cfcd439: avcodec/hevcdec: Declare that VDPAU can handle HEVC 4:4:4 content
[20:56:19 CEST] <BBB> philipl: I think you should feel totally comfortable in voting no, you seem to think you owe someone an explanation or an apology; you don't, it's a totally fair position to take
[20:56:48 CEST] <BBB> (even if some other project members disagree with you, probably including me :) )
[20:56:54 CEST] <BBB> that's fine, it doesn't matter
[20:57:22 CEST] <BtbN> So far everyone who "dared" to vote no was immediately asked to explain themselves...
[20:58:35 CEST] <BBB> I believe it's only 1-2 people who are "militant" about it, most of us accept varied opinions
[20:59:16 CEST] <BBB> (I hope)
[20:59:19 CEST] <durandal_1707> who?
[21:03:14 CEST] <BBB> carl appears to have some fairly strong opinions afaics
[21:09:15 CEST] <cehoyos> Why do you think so?
[21:09:33 CEST] <cehoyos> (Or to rephrase: Why do you think the patch wasn't applied quicker?)
[21:12:12 CEST] <durandal_1707> cehoyos: i think you forgot to attach patch for @ bug
[21:12:22 CEST] <cehoyos> philip: Why do you believe that it wasn't removed "as a direct response to the licence violation"?
[21:12:24 CEST] <cehoyos> Thank you!
[21:20:33 CEST] <durandal_1707> ah, this bug is about URI encoding? that is one big mess (URI encoding)
[21:32:28 CEST] <nevcairiel> URIs are complex no doubt, but piling hacks upon hacks to try to support out-of-spec characters in them seems like a bad idea
[21:32:41 CEST] <nevcairiel> thats what percent encoding was invented for :)
[21:34:49 CEST] <philipl> nevcairiel: '@' is not out-of-spec. https://tools.ietf.org/html/rfc3986
[21:34:59 CEST] <nevcairiel> I didnt say that
[21:35:17 CEST] <nevcairiel> but / in username passwords is, which is what the original commit that introduced the issue tried to support
[21:35:23 CEST] <philipl> ah. Sorry.
[21:38:32 CEST] <nevcairiel> eg. http://ffmpeg.org:80/foo@bar .. nothing prevents anyone from itnerpreting the host/port as username/password .. except if you forbid slashes.
[22:02:20 CEST] <BBB> cehoyos: I wasn't talking about a patch, I was talking about you specifically singling out contributors who voted "no"
[22:07:34 CEST] <cehoyos> I don't think I "singled them out": I am curious what they suggest, the only answer I received was "put them on shame".
[22:09:13 CEST] <cehoyos> Doing nothing is of course an alternative, but I had a feeling that this was not what people have in mind (and nobody suggested that).
[22:11:00 CEST] <durandal_1707> we removed shame list, why?
[22:21:49 CEST] <cehoyos> The "new team" removed theirs and we didn't want to look bad (afair).
[22:21:56 CEST] <BtbN> I mean, there isn't much to suggest what to do instead when voting No to the one question that's actually for vote.
[22:22:13 CEST] <BtbN> It's a Yes/No Question after all
[22:26:53 CEST] <cehoyos> That reminds me: Do you think the (first) question makes sense at all?
[22:27:27 CEST] <cehoyos> I believe we have to agree on something "to do" if we decide to revert the commit, doing nothing is a possibility but it should be clarified.
[22:27:51 CEST] <cehoyos> I somehow expected those who voted in favour of the revert that they know what they prefer as alternative.
[22:28:24 CEST] <cehoyos> (Including doing nothing)
[23:52:18 CEST] <BtbN> Doing nothing essentially boils down to a no, doesn't it? I took a No as equivalent with reverting the removal.
[23:52:22 CEST] <BtbN> *To a yes
[23:53:44 CEST] <cehoyos> Too difficult for me to parse, sorry...
[23:54:09 CEST] <cehoyos> My questions were: What should be done instead of removing libndi?
[23:54:53 CEST] <BtbN> Not removing it, i.e. reverting the remove.
[23:55:01 CEST] <cehoyos> Yes.
[23:55:35 CEST] <cehoyos> But the question is: If libndi is not removed from the FFmpeg codebase, how should we react to the copyright violation?
[23:56:06 CEST] <cehoyos> Doing nothing is a possibility, but it at least has to be an explicit choice.
[23:56:15 CEST] <BtbN> They removed the violating binary immediately, as with prior violators, I don't see any need for further action.
[23:56:28 CEST] <cehoyos> And so far, nobody suggested doing nothing, so I assumed that this is not the alternative.
[23:56:35 CEST] <BtbN> There are way worse violators who even just kept at it despite better knowledge.
[23:56:53 CEST] <cehoyos> Please stop this: They did not remove the binary immediately, and of course, removing the binary does not fix the violation.
[23:56:59 CEST] <BtbN> And the course of action there also boiled down to writing them on a list of shame and call it a day, if at all.
[23:57:25 CEST] <BtbN> What else could they possibly do? Asking them to release the sources of their entire product is ridiculous.
[23:57:33 CEST] <cehoyos> But if your suggestion is "no further action" that's good to know: I assumed it was not on the table to endorse a company that has violated our copyright.
[23:57:45 CEST] <cehoyos> That's what Amazon did...
[23:58:01 CEST] <cehoyos> And that is what US copyright law requires them to do anyway.
[23:58:06 CEST] <BtbN> I doubt they did that because of a a GPL violation.
[23:58:19 CEST] <cehoyos> Sorry? Please elaborate.
[23:58:35 CEST] <BtbN> What exactly did Amazon open source?
[23:58:40 CEST] <BtbN> Never heard of that.
[23:59:19 CEST] <cehoyos> They distributed an FFmpeg binary linked against a third-party library that to the best of my knowledge was proprietary.
[23:59:41 CEST] <BtbN> And yes, Newtek did release a new version of their SDK within hours of being notified. They did indeed not remove old releases right away, so deep links to prior versions still had it.
[23:59:43 CEST] <cehoyos> After they were informed of the copyright violation, they provided the sources for the library.
[00:00:00 CEST] --- Mon May  6 2019