Hi Thilo, 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.) Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel