memory usage increases (maybe a little O.T.)
DirectShow programming library for .Net programmers
Brought to you by:
snarfle
Menu
▾
▴
Hi all and happy new year 2015.
I have a player that uses the gmfbridge to play seamlessly some video clip.
In my player, I have two clips, one is playing, the other one is cued, and when the first one is over, my player plays the second one, then dischard the first one (disposing it) and cues a third one.
I'm experiencing a memory usage increasing, and I'm investigating about that. I've already read the "readme" document included to the library, but I still have some doubts.
For each source graph, I insert manually some codecs, for example if I'm working with some mpg files, I load the MainConcept audio and video codecs by using the System.Activator.CreateInstance(Type.GetTypeFromCLSID(CLSID)) method, where CLSID is the System.Guid of my codecs, and then by casting the returned object to an IBaseFilter object.
Do I need to release manually the obtained object? In case, when and how?
Actually I'm releasing the object by using the Marshall.ReleaseComObject method when the clip entity is disposed. Is it right?
I didn't understood when I need to use the FreeCoTaskMem method to release the resources.
Can you help me?
Thank you and again, happy new year!
The concept of memory handling in c# is not a simple one (and I am NOT an expert on c# memory systems). The whole idea of garbage collection is to let memory usage grow, then release it "at a convenient time." So when you say you are "experiencing a memory usage increasing", my first response is: Yep, that's what happens in c#.
But sometimes there are good reasons to release objects in a timely manner. For example, some filters hold files open. If you want to open those files elsewhere, the filter needs to let go. In theory, any time after you have added the filter to the graph, you should be able to call ReleaseComObject on an object created with Activator. Keeping the Graph object is enough to keep the filter loaded.
As for FreeCoTaskMem, that's a bit trickier. Mostly, you never need to use it. c# handles most of this for you. But, there are a few specific cases where it doesn't, mostly just when you call a function that returns a structure. All I can do is point you do the function descriptions in MSDN. Check out the descriptions for the functions you are calling.
And yes, sometimes memory growing can be a sign of some more serious problem (including some badly written filters that leak), but it's hard to give specifics with your rather general question.
Hi Snarfle and thank you for your answer.
Yes, I know the general rules about GC, so I know that a memory release isn't "real-time". In fact, I'm not worried about .net objects, but about unmanaged objects.
I'm doing some tests, and I'm paying attention to all unmanaged objects that I create in my application.
I'll have some other results in a few days.
Thanks again.. Maurizio
The Toolkit sample have a method called RemoveAllFilters that remove and release every filters from a graph...
Thanks to all.
I'm doing some tests and it seems to be a trouble with the MainConcept codecs.
I'm using that codec to decode the mpeg video files, but if I use the Elecard, seems to be ok. If I install the Elecard codec together to the Mainconcept, and I use the Mainconcept codec, it seems to work right.
Just a little thing.
When i install the Elecard codecs, the Mainconcept ones are broken by the Elecard, so it's impossibile to work with Mainconcept if installed togheter with Elecard. If I use Elecard, no memory increase observed.
I'm trying with Mainconcept 8.8.0
One of the inherent problems with filters is that you are at the mercy of the person who wrote them. And some of them are not well written. This can become a particular problem on distributed apps, since you never know what users might have installed on their machines. You might want to look at Misc\BlackList or maybe even reverse the logic and create a whitelist.
snarfle, thanks for the asnwer.
Actually I'm using something like a possible WhiteList, in fact I'm calling explicitally the codec I want to use. One of the best codec is, in my scenario, the MainConcept one, and I use it by adding it manually on my graph. The problem is that also the Mainconcept has some troubles, such as the release of something. Problem solved by using an older version.
FYI I'm having a similar issue with the GMFBridge - I'm using it to join clips together for transcoding.
I have a system where I have two source graphs built and the destination (encoding) graph. When a source graph has finished I switch to the other source graph, play that, and meanwhile clean up. I have to reuse the filter graph and the sink or it confuses GMFBridge, so I throw away all filters but the sink (remove filter from graph, call Marshal.FinalReleaseComObject) and then build a new decode chain of filters connect to the sink and run that etc. Over time I see memory grow - after around 50 repetitions I've hit 1GB of usage. I too am using some MainConcept filters interestingly.
If I find a good solution I'll post something.
One question - if I have created interface references to configure filters or the graph, e.g. IMediaSeeking do I need to release all those too, or is it enough just to do a release on one instance of the filter or graph object? In my mind I'm thinking of reference counts, so am trying to release every instance.
Hi Menatur,
In my case, when a clip is over, I destroy the graph, so the sink is destroyed too; then I create another "totally new" graph, and it is wokring for me. I don't know why you need to take the sink filter alive.
About the interface, such as IMediaSeeking, as far as I know, you don't need to release the interface, just the filter or the graph object at the end of theyr lifes.