Issue 174 in mp4v2: Ability to free memory allocated by MP4GetTrackH264SeqPictHeaders function

[mp...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 174 by Nicholas...@gmail.com: Ability to free memory allocated by
MP4GetTrackH264SeqPictHeaders function
https://code.google.com/p/mp4v2/issues/detail?id=174

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.

Attachments:
MP4FreeH264SeqPictHeaders.patch 2.7 KB

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[mp...@googlecode.com]

Comment #1 on issue 174 by kid...@gmail.com: Ability to free memory

allocated by MP4GetTrackH264SeqPictHeaders function
https://code.google.com/p/mp4v2/issues/detail?id=174

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.

[mp...@googlecode.com]

Updates:
Status: Fixed

Comment #2 on issue 174 by Nicholas...@gmail.com: Ability to free memory

allocated by MP4GetTrackH264SeqPictHeaders function
https://code.google.com/p/mp4v2/issues/detail?id=174

(No comment was entered for this change.)