bmdtools
bmdtools copied to clipboard
lu-zero
Memory leak (?) when capturing from certain sources
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.
On Thu, Jan 24, 2013 at 2:41 AM, Adrian Yee [email protected] 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
you might try libbmd with my Libav integration (see the README for some instructions)
Could you please run massif and paste the ms_print results? I'd like to see exactly where the memory is piling up.
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?
On Sat, May 18, 2013 at 12:53 AM, klarkc [email protected] 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.