[FFmpeg-devel] FFmpeg code Attribution

[Aaron Boxer]

Hi Alex,

On Thu, Mar 24, 2016 at 10:49 AM, Alex Beregszaszi <alex at rtfs.hu> wrote:

> On Thu, Mar 24, 2016 at 2:44 PM, Aaron Boxer <boxerab at gmail.com> wrote:
> > On Thu, Mar 24, 2016 at 12:55 AM, Reimar Döffinger <
> Reimar.Doeffinger at gmx.de
> >> wrote:
> >
> >> On Wed, Mar 23, 2016 at 10:50:06PM -0400, Aaron Boxer wrote:
> >> > On Wed, Mar 23, 2016 at 9:48 PM, Ricardo Constantino <
> wiiaboo at gmail.com>
> >> > wrote:
> >> >
> >> > > On 23 March 2016 at 22:35, Aaron Boxer <boxerab at gmail.com> wrote:
> >> > > > Back to my original point, what is the reasoning not to just
> switch
> >> to
> >> > > > OpenJPEG?
> >> > > Both OpenJPEG 1 and 2 are supported to add as external libraries in
> >> > > FFmpeg. What do you mean by switching to OpenJPEG?
> >> > >
> >> >
> >> >
> >> > I mean abandoning FFmpeg j2k codec, which seems to be a
> less-featureful
> >> > copy of OpenJPEG,
> >> > and putting resources into fixing OpenJPEG issues and making it
> better.
> >> > Since OpenJPEG
> >> > has a much broader user community, this would help both FFmpeg users
> and
> >> > many others.
> >>
> >> I wonder if you mean only the encoder or also the decoder...
> >> In general: competition and alternatives are good.
> >> Every standard should have multiple viable implementations.
> >> Of course if much code is shared/copied that weakens the argument
> >> a lot.
> >> However when it comes to decoders I do consider it important
> >> for FFmpeg to have its own implementation even if there are
> >> such shortcomings.
> >> If for no other reason that having all implementations in
> >> a shared code base, with shared concepts that allows to
> >> compare and find common approaches much more easily seems
> >> a very important thing to me which nobody else provides.
> >> Every external codec re-invents their way of writing
> >> bitstreams, VLC codes, ... making it hard to impossible
> >> to share code or even concepts.
> >> Plus there is a good chance that FFmpeg will still be
> >> maintained by the time quite a few of those external
> >> libraries have become unmaintained and suffered of bitrot.
> >> In some ways I think I'd consider sharing test vectors
> >> a possibly more important way of cooperating with
> >> other projects than sharing code.
> >>
> >
> >
> > Yes, monoculture is not good. But, one also doesn't want to expend
> precious
> > resources re-inventing
> > the wheel. It's a balance.
> >
> > I feel that JPEG 2000 is a bit of a unique case - it is probably one of
> the
> > most complex
> > standards around, and most of the complexity (for example parsing the
> file
> > format and code stream)
> > is not, to my knowledge, shared by other codecs. So, the advantage you
> > mentioned of re-using
> > structures across codecs does not really apply to J2K.
> >
> > FFmpeg j2k codec was written almost 10 years ago, seemingly as a partial
> > copy of OpenJPEG, and it is still inferior to it.  So, my guess is that
> > OpenJPEG will continue to be the better choice, unless you can
> miraculously
> > summon an army of developers and, equally importantly, users, for the
> > FFmpeg codec.
> >
> > I agree about sharing testing vectors. The OpenJPEG test suite is quite
> > extensive.  But, I'm not quite sure how to share
> > it with FFmpeg. It relies on ctest framework from Kitware, which doesn't
> > really fit with FFmpeg environment. Someone would have to re-write all of
> > the tests.
>
> Aaron, I am really wondering what is your goal here.  Do you want the
> JPEG2K implementation be removed from FFmpeg?
>

My goal on this thread is to point out unattributed OpenJPEG code in
FFmpeg.


>
> My impression based on the first thread was that you would be
> interested in having your AGPL implementation included.  Later you
> have mentioned that you don't want to have it included.
>

Never hoped to include my implementation, just looking for the correct way
for me
to make it available for those who are interested.


>
> Based on past examples I think an implementation would be removed in
> the following cases:
> a) there is a superior new FFmpeg-specific implementation available
> (and not an external library)
> b) it is broken beyond repair
>
> Do any of the following cases stand today?
>

I guess not. Although, I wonder why an external library is not acceptable.

Anyways, the important thing here is to ensure that code from other
projects gets proper attribution.
I'm sorry for going off topic about codec pros and cons.

Cheers,
Aaron