On 4/23/18, Thilo Borgmann <thilo.borgm...@mail.de> wrote:
> Am 23.04.18 um 22:47 schrieb Paul B Mahol:
>> 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.
>
> And you're welcome to do so. How is it an argument to have everyone to obey
> that?
>
>
>>> 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.
>
> If an REd native implementation comes around, that would be a good thing.
> And it would void the need of having a wrapper for what we natively support
> immediately, even if we would most likely keep it until next minor(?) or
> whatever change.
>
> Paul, I'm really interested in why having such code in FFmpeg is a thread to
> our project.It is big threat. If you want it, fork FFmpeg, call it BinaryBlogFFmpeg and do with it whatever you can. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
