Memory leak (?) when capturing from certain sources

[brewt]

We're capturing video from phones using Blackmagic Intensity Pro cards and we've noticed that when capturing from a Samsung Galaxy Nexus, bmdcapture's memory usage will grow slowly (after 2 minutes of recording, it gets to about 1GB of resident memory usage).

In comparison, an iPhone 5 will sit at around 120MB of resident memory usage (it does seem to grow, but very slowly and we're talking maybe 1MB a minute).

Is there something with the Galaxy Nexus' HDMI output that would be causing this? They're both outputing at 720p 60 fps.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/942864-memory-leak-when-capturing-from-certain-sources?utm_campaign=plugin&utm_content=tracker%2F256764&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F256764&utm_medium=issues&utm_source=github).

[lu-zero]

On Thu, Jan 24, 2013 at 2:41 AM, Adrian Yee notifications@github.com wrote:

We're capturing video from phones using Blackmagic Intensity Pro cards and we've noticed that when capturing from a Samsung Galaxy Nexus, bmdcapture's memory usage will grow slowly (after 2 minutes of recording, it gets to about 1GB of resident memory usage).

I tried to plug the evident leaks using valgrind, there was something
bogus in my way of using ->Release() (wrong assumption possibly) yet
if you still have problems would be great if you try running it in
valgrind and report back.

If the problem is on the decklink side I'd ask you to pressure
decklink to release a lower level api (possibly in C) so I can make
better tools.

Is there something with the Galaxy Nexus' HDMI output that would be causing this? They're both outputing at 720p 60 fps.

Never tried myself I have a galaxy but I don't have a cable.

lu

[lu-zero]

you might try libbmd with my Libav integration (see the README for some instructions)

[lu-zero]

Could you please run massif and paste the ms_print results? I'd like to see exactly where the memory is piling up.

[klarkc]

Maybe this is a issue with the bmdcapture buffer? I tested a lot here, in a live stream environment and bmdcapture won't drop old frames to use new ones, instead buffer to ram until the max reached ( -M option) and so, just quit.

If you use an encoder like ffmpeg with x264 without zerolatency tune any peak in cpu usage will increase the latency and memory usage. I don't know if ffmpeg have any options to drop frames if any limit is reached.

If you code few lines to just renew frames and flush memory instead of just quit will not resolve this issue?

[lu-zero]

On Sat, May 18, 2013 at 12:53 AM, klarkc notifications@github.com wrote:

Maybe this is a issue with the bmdcapture buffer? I tested a lot here, in
a live stream environment and bmdcapture won't drop old frames to use new
ones, instead buffer to ram until the max reached ( -M option) and so, just
quit.

That is on purpose.

If you use an encoder like ffmpeg with x264 without zerolatency tune any

peak in cpu usage will increase the latency and memory usage. I don't know
if ffmpeg have any options to drop frames if any limit is reached.

ffmpeg is anyway not supported.

If you code few lines to just renew frames and flush memory instead of
just quit will not resolve this issue?

I can optionally make so it drop frames, but is not solving the problem.

Here you have some different problems due memory usage not leak.

• if you are slow in consuming frames capture they keep piling up, it is
  done by design assuming you might have temporary slow downs.
• NUT as implemented in Libav due a design assumption (you want to have the
  full index at the end even if it is optional) keeps piling up some memory,
  it is not huge but if you plan to use the normal mode for months you
  might just use enough to cause problems, I wrote an experimental pipe mode
  that doesn't have the problem and has even less overhead.

I'm sorry for being slow in updating bmdtools so you have at least the
issues better documented.