video source - avi decompress - h264 encoder - dvd decoder - evr
I've tried with more advanced graphs and graphs such as file writing and different decoders, and different capture sources. The leak continues to happen however if I then go into the encoders property pages, and set the preset to "Normal", the leak all of a sudden goes away and the process (in task manager) increases a bit and then decreases and continues to do this but never goes over a certain limit which tells me its releasing com objects successfully.
Does anybody else see this? I just upgrade to beta 5 hoping it would fix it and before i was using beta 4. Thoughts, suggestions, concerns, ideas??
We will look into this and get back to you as soon as possible.
Just so that we can establish environment baseline, could you please provide some more info:
The isolated example I did by using just graphedit; pulled the intel media sdk h.264 encoder into the graph and the default preset is User Defined. Target Usage is Balanced and bitrate is 6000. If I switch it to a normal preset it goes away. However in the application the end user will be able to select from the presets and categories the filter provides. And in the application the default settings are all set to automatic for simplicity on the users end.
I am running the filters on a machine that supports HW acceleration and tried it on a second machine to confirm. Just to confirm, is this an automatic flag or do I have to set something to enable hardware acceleration? I do notice the CPU jumping when encoding... could be the issue?
I have not made any changes to the encoder. I am using the beta 5 h264_enc_filter.dll and ultimatelly pulling it into a directshow graph via c#.
If I do manage to get HW encoding working properlly, I'm assuming the memory leak would go away however does this cause any concern on the hardware level?
I did look into the issue you reported and I have identified a memory leak in the Media SDK DirectShow encoder sample. The issue does not seem specifically tied to HW or SW encoding. We are looking into a solution and will provide more info to you as soon as possible.
Thanks for helping us make Media SDK better!
Thanks again for reporting the issue. The DirectShow sample code bug will be fixed in the Gold release of Media SDK 2012 which is due for release a couple of weeks from now.
I've got it in our database to be investigated, but its a national holiday in Russia and we are a bit short staffed this week. Is this a critical problem for your product launch?
Heres the current scenario... we use the encoder in the medical workspace and our installer is currently onsite and leaves saturday morning, which gives me today and tomorrow to apply a fix.
It is very crucial we get this working because as of right now the memory issue when too high starts to affect the overal performance of our application and destroys the our mp4 muxer thus ending a recording too soon, 1 hour recording may only have 20 minutes. In a surgery this is bad!
Anything you can do to streamline the process of the memory leak would be greatly appreciated,
We have until the end of today to complete this project for the clients sake and ours... if version 2 is more reliable then it might be best to downgrade for now?
Are there any updates relating to the memory leak in version 3?
"mark that Receive function is responsible for freeing memory"
Is this a statement towards someone named Mark or is this like marking the line where were suppose to free memory?
Petter and I have been trying to debug this since yesterday afternoon. Unfortunately, its not really apparent where the leak is coming from. We continue to debug..
I certainly can provide the 2.0 DShow encode sample. I confirmed that this filter does not have the same memory leak however, there are some limitations with this sample as well. The 2.0 sample does not have YUY2 input pin support. We added that with 3.0.
We are continuing to look at the problem today, and I hope to have something to say later today.
If you want me to transfer MSDK 2.0 sample to you, please write me directly at: firstname.lastname@example.org to coordinate the transfer.