[FFmpeg-devel] FFmpeg code Attribution

[Alex Beregszaszi]

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

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?

Best,
Alex