serious memory leak

[brabebhin]

There is a pretty hefty memory leak in this project. I am not entirely sure from where, but a spike of 13MB upon opening a file is pretty damn impresive.

There is also a problem in the media stream source initialization. The buffer time needs to be zero to avoid pause/resume issues.

[yodurr]

Thanks for logging this. If you can share the specific file you're opening that might help.

[brabebhin]

I am trying to use this with background media player in windows phone. You can pretty much use any actual music file with any codec supported to reproduce the issue. memory consumption spikes from an idle of 5MB to 13+ upon opening any file. There are files which aren,t even opening, especially those with album art.

The high memory usage might be related to custom file io. I will upload an example file later. The worse part is that moving to other files only leaks more memory.

[brabebhin]

So is there any email address I can send the file to? I don't wanna post the link on the public interwebz :P

[khouzam]

We have identified the issue with the album art not playing. The album art stream is detected as a video stream and causes the playback to stop.

I'm not sure that the memory usage you're seeing is a memory leak or just the memory necessary to load the media pipeline and decoders. I would love to see your project because I'm surprised that the custom file io works with the phone background audio model. How are you opening the file in the background process?

You can send me info to: gillesk@companyname.com (I assume you can infer the company name from the repository).

[brabebhin]

I've sent you an email with some information ^^

[khouzam]

@mcosmin222 would you mind posting how you've solved this issue.

Thanks

[brabebhin]

Umm, solve which issue exactly? The one with play/pause?

[khouzam]

The high memory usage that you saw.

[brabebhin]

You can't fix it since the ffmpeg interop project will automatically load the dlls into memory, which is the apparent source of the high memory usage. I reached this conclusion because the memory level increased before opening an actual file, but when first calling into a ffmpeg function.

What you can do is limit the overall memory consumption, by using a C++/CX based background audio task instead of a C# one.

[yodurr]

Two recommended workarounds to this issue.

One you mentioned: "limit the overall memory consumption, by using a C++/CX based background audio task instead of a C# one. "

The other is in how you are building ffmpeg libraries by only including the codec libraries you are going to use. This will reduce the memory footprint by some amount.