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

[compn]

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.

> >> >> 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


> 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?

> 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.

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.

> 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.

i could be wrong, and thats why we need more opinions from commercial
ffmpeg users. i only speak for myself, not the project.

-compn