Ability to free memory allocated by MP4GetTrackH264SeqPictHeaders function

[GoogleCodeExporter]

Issue:
If a client application wishes to extract H.264 video data from an MP4 file 
then it can call a few publically exported mp4v2 API functions to get track 
information and track data.  One of these functions is 
MP4GetTrackH264SeqPictHeaders(), which will provide the sequence and picture 
parameter sets.

This function allocates memory to hold the parameter sets and passes that 
memory to the client application.  The client application is not in a position 
to free that memory directly.  This is the case because the mp4v2 library is 
built as a Windows DLL.  The client application's CRT heap manager cannot free 
the memory that was allocated by the mp4v2 DLL's CRT heap manager.

What I have seen in other open source applications is that they do not free the 
memory.  These applications get away with that because they are typically 
console applications that perform a task and then exit, at which point the 
operating system reclaims the memory.

This is not a solution for me because the software I am working runs 24/7 
receiving MP4 encapsulated H.264 video.  The software uses the mp4v2 API to 
extract the H.264 video.  Repeated calls to MP4GetTrackH264SeqPictHeaders will 
eventually leak too much memory.

Environment:
Windows NT operating system platform, specifically XP and 7 (although issue 
applies to all versions).

mp4v2 is built as a DLL using Microsoft Visual Studio 2010.

Solution:
Provide an explicit API function to free the memory that was allocated by 
MP4GetTrackH264SeqPictHeaders.

Patch:
I have provided a patch for the issue.  I've added a public API function to 
free the memory allocated by MP4GetTrackH264SeqPictHeaders.  The implementation 
is simple and straight forward.  I've provided a comment block that uses the 
Doxygen keywords.  The patch adheres to the coding style of the neighboring 
functions.

Testing:
I do not have unit tests provided or any kind of thorough testing results, with 
respect to the testing infrastructure of the mp4v2 source tree.  The patch I 
provided has been compiled and used in my development environment.  I have ran 
a successful run of the software.  I have also stepped debugged my code and the 
mp4v2 code to verify the actions taken by the implementation in the patch.

Original issue reported on code.google.com by Nicholas...@gmail.com on 7 Oct 2014 at 8:26

Attachments:

• MP4FreeH264SeqPictHeaders.patch

[GoogleCodeExporter]

Looks good, and I agree it's a nice function to have.  I have that exact 
deallocation code more or less duplicated in places where I've used that call, 
so it makes sense to have it be an API call so there's no ambiguity over how to 
free up that memory.

I can make you a maintainer so you can push?  Beyond that, I don't have time to 
deal with this library right now.

Original comment by kid...@gmail.com on 14 Oct 2014 at 3:24

[GoogleCodeExporter]

Original comment by Nicholas...@gmail.com on 17 Oct 2014 at 10:07

• Changed state: Fixed