[FFmpeg-devel] [V3 PATCH 0/3] Codec wrapper for librv11 and RMHD muxer/demuxer
Ronald S. Bultje
rsbultje at gmail.com
Mon Apr 23 22:03:57 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:
> >>> 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
> > 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
More information about the ffmpeg-devel