On 4/23/18, Thilo Borgmann <thilo.borgm...@mail.de> wrote:
> Hi,
>
>> not expressing specific agreement or disagreement.
>>
>> On Mon, Apr 23, 2018 at 2:43 PM, Thilo Borgmann <thilo.borgm...@mail.de>
>> wrote:
>>
>>> Am 23.04.18 um 03:36 schrieb James Almer:
>>>> On 4/22/2018 6:43 PM, Paul B Mahol wrote:
>>>>> On 4/22/18, Thilo Borgmann <thilo.borgm...@mail.de> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> V3 drops the MLTI part, no idea how it survived
>>>>>> 02fff499362daedcdcb0a9cdd517257843600563 on our side...
>>>>>> Also dropped audio override, could not get a sample requiring it.
>>>>>>
>>>>>> Adapted to current HEAD.
>>>>>
>>>>> I'm strongly against applying this to our tree.
>>>>
>>>> The de/muxing code can and should be applied as long as there are not
>>>> technical limitations. They are native code and depend on nothing
>>> external.
>>>>
>>>> And regarding the decoder and encoder wrappers, you need to explain the
>>>> reasons for your hard NAK...
>>>
>>> Yes Paul please do, and while you're on it, please add your thoughts
>>> about
>>> making it good enough for our tree that come to your mind. I assume it is
>>> not RV11 or its library wrapper for itself you don't like to see
>>> pushed...
>>
>>
>> So, let's take the hypothetical argument of the encoder. So, clearly, the
>> company ("they") offering that encoder makes money and would benefit
>> financially from seeing that encoder integrated with FFmpeg. Also, the
>> maintenance effort would fall entirely on the opensource community ("we").
>> For example, if we change API (big or small), we have to update their
>> wrapper. However, their encoder itself (not wrapper) is still
>> closed-source. So, it seems very one-sided in terms of who benefits at
>> what
>> cost and to who.
>>
>> My impression has always been that for opensource encoders, we were OK
>> with
>> this trade-off (there is GPL vs. LGPL etc., but we make it work in a
>> variety of ways). For example, even though x264 is GPL, we (LGPL) are OK
>> with that, since GPL is still opensource, and for many end use cases, that
>> works out fine anyway. However, for closed-source encoders, Iv'e always
>> assumed that our default position is "no, thanks", and recommend these
>> companies to maintain their patchset out-of-tree, so the cost of updating
>> is on them, not us.
>>
>> Hypothetically, again, let's say this patch (encoder wrapper, or even
>> decoder wrapper) went in, does that mean my companies' VP9 encoder wrapper
>> can go in also? What about commercial H264/HEVC encoders? (There's many of
>> them.) How do we decide which goes in if there's many and we don't know
>> their quality/speed at various use cases because we don't have access to
>> these under liberal licenses we are all comfortable with?
>>
>> (No specific opinion intended, just putting a wider frame on the
>> discussion.)
>
> I totally see your point in us having to care for the wrapper if it is not
> out-of-tree. Also that this is or might easily be a financial saving for a
> company.
>
> I don't see us having a maintenance burden that big to refuse such code just
> of that, though.
> Of course, feeling "used" by a company to do "their" work adds to a negative
> impact. I added myself to be maintainer of that code in question and I don't
> feel that way (and no, I'm not on a permanent payroll of RealNetworks).
>
> Thinking of code that is not getting the devotion of any maintainer - we
> just removed that code in the past and why should that not happen to a
> wrapper utilizing a commercial binary. A company who wanted such a wrapper
> and shows no further interest in maintaining suffers from removed support
> sooner or later. Which might raise their interested again, doesn't it?
>
> From the users perspective I don't see why we don't have wrappers for a
> commercial codec. If the user wants to use it, why should we forbid such
> code. Having an out-of-tree repo to merge into the code for supporting such
> codec _is_ of course a way for the user to get it anyway. But from that only
> the users compiling & patching the code themselves are capable of doing so
> benefit - we lose sight of all others going that way.
>
> Paul and Rostislav adding a concern about killing the project with it by
> supporting closed source solutions.
> I don't get your big picture with that concern. I don't see how FFmpeg
> supporting external commercial codecs is a threat to our project. Please
> enlighten me and I'm serious about it. When I was asked about helping with
> such a wrapper for that library, my "natural" intention is to get FFmpeg
> support it if we don't have native or other support for that codec - to
> support every codec there is, which is one of our goals, isn't it?Please, I'm not supporting binary blobs, nor do I intend to use them. > > I can't stress enough how seriously I want you to explain me your point of > view. I'm doing a lot of things in the best interest of FFmpeg, I'm spending > money in the name of the project, talking to a million different faces about > it and if "go with an out-of-tree wrapper" is our opinion on that for a > reason I want you to convince of that. Give me a call if you feel to, I mean > it - I don't care much about a commercial flaming discussion nor do I want > to make a point about the topic, I care about an important point I might not > aware of so far. I benefit from getting this wrapper through review, however > it is out of the question that no money in the world will bribe me to act > against the best interest of FFmpeg. Convince me having such code is a > really bad idea for the project and I will waive my whole effort for this > case and maybe be better able to protect our project from such endeavors. If this codec is useful at all, and used a lot, it will be REd in days. Then we would need to keep wrapper for how much long? Maintaing wrapper is out of question when there is native decoder. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
