[FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 1:51 PM, Timothy Gu <timothygu99 at gmail.com> wrote:

> On Sun, Apr 03, 2016 at 05:34:15PM -0400, Aaron Boxer wrote:
>
> > From d12c685578f21b403f6c03505edd84db367306c5 Mon Sep 17 00:00:00 2001
> > From: Aaron Boxer <boxerab at gmail.com>
> > Date: Sun, 27 Mar 2016 00:15:20 -0400
>
> > Subject: [PATCH] Support the following jpeg 2000 codecs:
> >
> > a) latest release of openjpeg (2.1)
> > b) master branch of openjpeg
> > c) grok (https://github.com/GrokImageCompression/grok)
>
> The commit message should be changed to:
>
>     build: Support additional OpenJPEG-compatible libraries
>
>     Support OpenJPEG 2.1, master, as well as Grok.
>

No problem.


>
> >
> > The following changes were made:
> >
> > 1. Removed bpp (redundant as this information is already stored in
> precision)
>
> Does compilation still work without this change?
>

Yes.



>
> > 2. Removed OPJ_STATIC flag in configure: in master branch of openjpeg
> and in
> > grok, this flag indicates a static build, so codec API functions are
> marked
> > as hidden. This prevents FFmpeg from using a dynamic build of these
> codecs.
>
> This will break Windows DLL MinGW support. See
>
> https://github.com/uclouvain/openjpeg/blob/master/src/lib/openjp2/openjpeg.h#L79-L108
> .
> When Windows is used and OPJ_STATIC is not defined, __declspec(dllimport)
> is used, which asks GCC to mangle
> the symbol name when compiling. However, under MinGW environment, such
> mangling doesn't work, since the DLL is all that is needed for linking
> under
> MinGW.
>

Let me look into this.


>
> Does the compilation of OpenJPEG break _now_ without the patch? If so,
> submit
> a bug report, if not, then this change merits further discussion.
>


Compilation against OpenJPEG master is broken, but everything works with
the latest release
of OpenJPEG (2.1)



>
> > 3. link to libdl. This is needed by grok, as it supports a plugin
> > architecture that allows plugins to be dynamically loaded at runtime.
>
> Is there a way to detect Grok? Linking to a library that is unnecessary
> for a
> specific case doesn't sound appealing to me.
>

Currently no way of detecting Grok vs OpenJPEG


>
> Also it should be made clear that if Grok is linked into FFmpeg, the
> resulting
> binary is a mixture of AGPL and GPL works. If --enable-gpl or
> --enable-version3 is not enabled, the compilation should fail.
>

No problem.


>
> If there isn't a way to detect Grok from OpenJPEG, there should be one.
>
> If it is not clear to you why we are so against AGPL, it is because it
> incurs
> additional restrictions on the work that we don't consider to be in the
> spirit
> of free software, regardless of what FSF says. But I think you already know
> about that.
>

Why do you consider it to not be in the spirit of free software?
So far, nobody has given me a convincing argument against the use of  the
AGPL.

Cheers,
Aaron



"I disapprove of what you say, but I will defend to the death your right to
say it"
Voltaire





>
> Timothy
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>