[FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs
timothygu99 at gmail.com
Mon Apr 4 19:51:23 CEST 2016
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.
> The following changes were made:
> 1. Removed bpp (redundant as this information is already stored in precision)
Does compilation still work without this change?
> 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
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
Does the compilation of OpenJPEG break _now_ without the patch? If so, submit
a bug report, if not, then this change merits further discussion.
> 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.
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.
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
More information about the ffmpeg-devel