memory resource leak via ms->cbhandle codebook memory

[invd]

GPMF_Decompress() allocates memory via GPMF_AllocCodebook(), but never calls free() on it via GPMF_FreeCodebook().
This is likely somewhat intentional, with the likely goal that repeated GPMF_Decompress() calls can skip the individual codebook allocation for performance reasons. According to my observations, GPMF_AllocCodebook() is fairly costly.
However, neither the GPMF_demo.c code nor the main parser code clean up the codebook at any point. One function where this would be required appears to be GPMF_Init(), since it resets the ms->cbhandle handler that points to the malloc'ed memory.

To make things more complicated, the struct behind GPMF_stream *ms is not cleanly initialized, which means that ms->cbhandle can be filled with uninitialized memory contents. Calling free() on those random pointers would crash.

This resource leak is likely not a significant problem during short operations (short CLI runs) but may lead to OOM situations in long-running processes.

[dnewman-gpsw]

It seems we need a GPMF_Free() match the use of GPMF_Init(), just in case a the payload contains a compressed stream. This will be in v2 of the API. Compressed streams total are very rare, only the GoPro MAX camera using it for the DISP stream (a displacement map at the stitch line, for internal use), however it is a good fix for future implementations that may need more compression.