Articles in this section

Releasing the SDK objects properly to avoid possible memory overflow

Medialooks' SDKs are based on the Components Object Model (COM) technology. Except for advantages, such as multiple programming languages, there are a few things to take care of. One of them is correct redistribution, and another one is releasing of objects.

High-level frameworks, like .NET, have garbage collectors that take care about memory releasing and let your coding be nice and easy. But when it wraps the COM objects like our SDKs it can play a bad trick. The unneeded .NET object can contain just a small link to the COM object, so garbage collector considers it lightweight garbage and postpones memory releasing. But the linked COM object can be really huge, so before garbage collector decides to erase it you may lose a lot of memory. To avoid this situation don't trust the garbage collectors and release all SDK objects manually.

Here are the situations you need to remember about.

Release the main SDK object that you have created and does not need any more

For example:

A temporary MFile object that you've created for service needs.

// Crearte MFile object for temporary needs
MFileClass objTemporaryFile = new MFileClass();
// ...
// play around with MFile object
// ...
// Close unneeded MFile object
objTemporaryFile.ObjectClose();
// Release it to free the memory
System.Runtime.InteropServices.Marshal.ReleaseComObject(objTemporaryFile); runby_bm_b24wcqadm A temporary MLive object that you have used to configure the source of MPlaylist or MMixer

A temporary MLive object that you have used to configure the source of MPlaylist or MMixer

Use safe events and release the objects that you get on events

That's the most important point as the event has risen on each frame it can create tons of unreleased objects within a couple of minutes. To be sure that there is no objects leak you should use safe events (OnFrameSafe instead of OnFrame) and release objects (frames and event objects) that you get on events.

Be sure that you release the SDK objects inside your .NET wrapper objects

The tricky thing is that if you'll call the release method in your custom object's destructor, it still will be called when the garbage collector decides to destruct it. That means that you still rely on garbage collector's intelligence and may have some memory load problems.

So to be absolutely sure that you release the SDK object manually we recommend to release it not in a destructor, but in a custom method that you will call to release the objects.

When you don't need it anymore

// Here is my new file wrapper
MFileWrapper fileWrapper = new MFileWrapper();
// ...
// playing around with it
// ...
// Release it when you don't need it anymore
if (fileWrapper != null)
{
fileWrapper.ReleaseInternalCom();
}

When you make the assignment.

The COM object can remain when you make assign operation. So we recommend you to release the object manually to be sure that there are no garbage COM objects in memory.

// Here is my new file wrapper
MFileWrapper fileWrapper = new MFileWrapper();
// ...
// playing around with it
// ...
// I want to make an assignment,
// so I will call the release method to be sure
// that no COM objects will remain in memory
if (fileWrapper != null)
{
fileWrapper.ReleaseInternalCom();
}
// now I can make assignment being sure that my memory is free
fileWrapper = myCachedFileWrapper;

Multiple object usage

If you are going to use create SDK objects multiple times don't forget to call

MPlatform

(m_obj as IMObject).ObjectClose()

The common method for close object - can be used for close any object

MFormats

(m_obj as IMFObject).MFClose();

The common method for close object - can be used for close any object e.g. instead ReaderClose, DeviceClose, SpltterClose etc.