[FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer
thilo.borgmann at mail.de
Tue Apr 24 00:06:51 EEST 2018
Am 23.04.18 um 22:47 schrieb Paul B Mahol:
> On 4/23/18, Thilo Borgmann <thilo.borgmann at mail.de> wrote:
>>> 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
>>>> 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
>>> 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
>>> cost and to who.
>>> My impression has always been that for opensource encoders, we were OK
>>> 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
>> 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.
More information about the ffmpeg-devel