Update to memory management

[GoogleCodeExporter]

The team at Ghostscript have asked me to contact you about the possibility of 
updating the memory management in OpenJPEG2.

In the event of an error condition arising, it can allow the calling app to do 
a complete memory cleanup. Another use case is on systems (usually embedded, 
but not always) where the system memory manager is poorly optimised for this 
type of application - being able to "hook" the memory calls allows a calling 
app to implement an optimised solution (for example, the chunk allocator in 
Ghostscript).

We've had cases where developers wanted Ghostscript to use their special memory 
manager calls, which is easy in Ghostscript  but means code changes in 
OpenJPEG2. A bug for this has been raised in Ghostscript and can be found at 
http://bugs.ghostscript.com/show_bug.cgi?id=694691. The bug report outlines the 
problems encountered and is hopefully a starting point for us to discuss a 
possible solution especially the API changes this would require.

The first step in these changes is to make opj_codec_private_t available 
through an include file. Once you are happy with this we can propagate the main 
context to the lower function calls.

The attached files have been tested on windows and Linux using OpenJPEG2.

Original issue reported on code.google.com by slmis...@gmail.com on 12 Jan 2014 at 3:52

Attachments:

• openjpeg2.patch
• opj_codec.h

[GoogleCodeExporter]

After a first analysis of this patch and the bug description, we cannot accept 
this patch.
 The opj_codec_private_t struct is private to avoid to expose the internal struct. 
If I well understand the problem is memory take by openjpeg to decode or encode 
a file ?
If you need we can discuss about how to used your memory function through 
OPJ_MALLOC/OPJ_FREE 

Original comment by savmick...@gmail.com on 13 Jan 2014 at 9:55

[GoogleCodeExporter]

Correct me,
You want set your malloc/calloc/free functions and give to openjpeg your 
user_data ?

Original comment by savmick...@gmail.com on 13 Jan 2014 at 10:27

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 25 Feb 2014 at 2:19

• Added labels: Milestone-Release2.1

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 25 Feb 2014 at 2:19

[GoogleCodeExporter]

Is this the only patch needed in current openjpeg trunk ? I'd like to get this 
merged for openjpeg 2.1.0, but would hate to introduced a half-baked feature.
Has it been tested somewhere ?

Original comment by mathieu.malaterre on 4 Mar 2014 at 10:47

[GoogleCodeExporter]

Mickael - The overall plan is to add a new void pointer (ctx) within 
opj_codec_private_t to provide the memory hook. Users would then call either 
opj_create_decompress(OPJ_CODEC_FORMAT p_format, void * ctx) or 
opj_create_compress(OPJ_CODEC_FORMAT p_format, void * ctx) accordingly. 

I wanted it to work in the same way that opj_event_mgr_t works so instead of 
callbacks for error/info/warning you would have malloc/calloc/realloc/free. 
However, for the event handler there are quite a few areas in the code marked 
TODO where an fprintf is used instead because the event handler is not visible. 
The patch above is the first step to make the codec visible internally and 
hence will ultimately resolve the current issue with the event handler as well.

Mathieu - The patch above is just the first step as outlined in the ghostscript 
bug listed above. It has been regression tested using the ghostscript test 
files.

Original comment by slmis...@gmail.com on 4 Mar 2014 at 10:50

[GoogleCodeExporter]

Ok, will upload as-is.

Original comment by mathieu.malaterre on 7 Mar 2014 at 9:43

• Changed state: Accepted

[GoogleCodeExporter]

This issue was closed by revision r2609.

Original comment by mathieu.malaterre on 7 Mar 2014 at 9:44

• Changed state: Fixed