On Mon, Apr 4, 2016 at 1:51 PM, Timothy Gu <timothyg...@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 <boxe...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel