[FFmpeg-devel] FFmpeg code Attribution

[Aaron Boxer]

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.

Best,
Aaron