[FFmpeg-devel] [PATCH 1/3] avformat/mxfenc: H.264 Intra support

[Robert Krüger]

First of all, thanks for taking the time for the detailed feedback.

On Thu, Sep 25, 2014 at 3:51 AM, compn <tempn at mi.rr.com> wrote:
> On Mon, 15 Sep 2014 14:07:06 +0200
> Robert Krüger <krueger at lesspain.de> wrote:
>
>> On Mon, Sep 15, 2014 at 1:12 PM, Michael Niedermayer
>> <michaelni at gmx.at> wrote:
>> > On Mon, Sep 15, 2014 at 10:26:28AM +0200, Robert Krüger wrote:
>> >> On Sun, Sep 14, 2014 at 5:58 PM, Michael Niedermayer
>> >> <michaelni at gmx.at> wrote:
>> >> > On Sun, Sep 14, 2014 at 05:40:35PM +0200, Robert Krüger wrote:
>> >> >> On Sat, Sep 13, 2014 at 12:36 PM, Michael Niedermayer
>> >> >> <michaelni at gmx.at> wrote:
>> >> >> > From: Baptiste Coudurier <baptiste.coudurier at gmail.com>
>> >> >> Just a general policy-question: will changes like this not in a
>> >> >> way discourage development of these features in ffmpeg under
>> >> >> LGPL? If someone now uses this code (e.g. mxf_parse_h264_frame)
>
> ffmpeg itself does not have license requirements (aside from being
> open source licenses), as we accept code from lots of people and
> companies, we have a few different licenses already.
>
> i guess like michael says, we prefer lgpl. but as this is a volunteer
> project, being volunteers, we probably wont spend time on relicense
> stuff unless we get paid to.
>
>
>> >> >> in other code they will have to make that GPL as well. In the
>> >> >> long run this will make life harder for library users who
>> >> >> cannot live with GPL. So far this hasn't been done on that
>
> they can pay for relicensing.

The experience with organizing the yadif relicensing did not exactly
encourage me personally to do this again anytime soon.

>
>> >> >> level, at least not in the part of code that I am watching.
>> >> >> AFAIR currently license borders are normally on a component
>> >> >> level, i.e. a certain codec, format, filter only works only
>> >> >> under GPL, not parts of functionality of a cocec, filter or
>> >> >> muxer, which I think makes it OK to track by people for whom
>> >> >> license matters. this extends this to a level where one would
>> >> >> have to know which features of a certain muxer, codec, filter
>> >> >> works under which license. Of course that's a project
>> >> >> maintainer decision. Just wanted to throw in that side of the
>> >> >> story, so it can be consciously taken into account or
>> >> >> disregarded.
>> >> >
>> >> > This isnt the first "#if CONFIG_GPL" in the code.
>> >>
>> >> Technically correct but I see only me_cmp.c and flac_dsp_init.c so
>> >> far and I don't know what the code does better with GPL. So far I
>> >> have not run into this as a library user and thus was not aware of
>> >> it. At least it seems to be a rare exception. I am afraid of the
>> >> situation it may create, if picking stuff from ffmbc and
>> >> introducing it via #if CONFIG_GPL becomes more common.
>> >
>> > I really think you are doing a "own goal" here
>>
>> I am not sure I understand what you mean by this. I am not trying to
>> hide what's my interest in this, if that's what you're referring to.
>> Also assuming this I am not alone in this situation, so I am bringing
>> this to your attention to consider as project maintainer, one of whose
>> goals might be to make adoption of ffmpeg in commercial
>> projects/software easier. I may be wrong but I interpreted vlc's move
>
> this is one of ffmpegs goals, but i dont think it is a high priority.
> we dont really have official priorities, but i think the unofficial
> list is something like this:
>
> 1. support all codecs
> 2. fastest support of all codecs
> 3. fastest support of all codecs and formats on all systems
> 4. have fun working on open source project
> 5. get paid to have fun working on open source project
> ...
> (bunch of goals not listed)
> ...
> 3144. make ffmpeg work for commercial applications easier

Oh, 3144 is indeed a bit worse than what I had thought/hoped. I
somehow thought "being the de-facto standard cross-platform library
for media (de)muxing/(de/en)coding/filtering" was sort of a nice goal
as well and being compatible with commercial use helps there.

>
>
>> to relicense as much code as possible to LGPL to be motivated by that,
>> potentially because they thought, the project benefits from this. I
>
> sure. and i agree, that probably helped them out in some way.
>
> theres an interesting question that i thought up during the
> libav-ffmpeg discussion at vdd14.
>
> are we as a project going to basically go into business for ourselves ?
>
> are we going to package ffmpeg as a lib for commercial operations and
> sell paid support as a vendor? make a few scripts and paralellize the
> code a bit, fix up threading and memory management.
>
> like x264 did. kind of like vlc did (getting on ios store etc)
>
> or are we going to continue operating as volunteers and paid
> consultants for individual companies?
>
> i think a few devels have done similar things on their own.
> should we do it as a group? can we even do it as a group or are we too
> independent to do it?

I wrote quite a bit about that in the yadif relicensing thread because
I had the feeling this is being brought up from time to time without
really thinking through, what that means
(http://article.gmane.org/gmane.comp.video.ffmpeg.devel/165567).
Summary: IMHO doable, but takes a lot of work and commitment to get
the legal and administrational stuff done and would totally change the
project and at the moment my gut feeling says the main drivers of
ffmpeg have other goals/priorities (which is completely
OK/understandable).

>
>> know there is the justified impression that commercial users don't
>> give back enough but I am convinced that at least tons of bug reports
>> and samples come from people who use ffmpeg to build commercial
>> software. Again, this is a decision the project needs to make. I am
>
> most companies wont let samples back to us, because of copyright laws
> and NDA.

Samples is one thing. I was thinking more generally about qualified
bug reports. I guess a significant portion of those comes from people
who make money using ffmpeg in their products but I may be wrong.

>
> as a maintainer of the samples repo ( samples.ffmpeg.org ) i'd say i'm
> not worried about getting samples from companies. yes its important to
> get samples from companies, but the majority of our samples are from our
> users and downstream users (mplayer, vlc, xine etc).
>
> again, if a company is using ffmpeg, they can pay us to get bugs fixed.
> which is what has happened a lot over the past and continues to happen
> to this day on the list. with companies asking for consultants to come
> fix their workflows.

Yes, paying for getting a feature implemented or a bug fixed is
perceived orders of magnitude easier that paying for relicensing.
That's sort of my point.

>
>> just pointing out that intermixing more GPL code in core places makes
>> life harder for those people, which, of course, includes us. That's
>> why I don't think this patch is a minor thing.
>
> i agree. its not a perfect sitation. i appreciate your analysis, we need
> clear communication from all ffmpeg users on all subjects. thank you. i
> think michael listed the solutions possible, i'm trying to think of
> other solutions as well.
>
>>
>> > do you prefer if i do this work in a seperate branch outside FFmpeg
>> > or what do you suggest ?
>>
>> No, the last thing anyone needs is another fork.
>>
>> In this particular case, maybe asking for a bounty for adding AVCI
>> support in the mxf muxer could be a way. But since this is more a
>> general question about project policy, maybe it should be defined, if
>> it is not defined yet. Of course, this might mean that a certain
>> feature, only available in GPL code in another project like ffmbc,
>> could not move into some places of ffmpeg code, if the project
>> maintainers/devs decide that this kind of LGPL user base is important
>> enough to them.
>
>
> but i'd like to say, i'd rather have ffmbc merged (and all other
> forks) into ffmpeg than worry about lgpl compat. the forks may have more
> features we lack and i think ffmpeg users care more about features.

Depending on how it's done that might be a complete catastrophe for
people like myself who rely on LGPL ffmpeg libraries and I can only
assume that there are a lot of them out there. But of course it's the
decision of the people actually doing the work for this project.