[FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer
thilo.borgmann at mail.de
Mon Apr 23 23:45:11 EEST 2018
> not expressing specific agreement or disagreement.
> On Mon, Apr 23, 2018 at 2:43 PM, Thilo Borgmann <thilo.borgmann at mail.de>
>> 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.borgmann at mail.de> wrote:
>>>>> 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
>>> 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
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?
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.
More information about the ffmpeg-devel