I use the Intel Media SDK 2016R2 (2016.0.2) in an application showing live feeds from multiple H.264 cameras. For some time now I have been tracking a memory leak. The leak is large enough that when decoding 16+ video streams in parallel, the memory leaked goes into the GB range within hours. Hooking the C/C++ allocator functions (new, malloc, etc.) in my application shows no allocated-but-unaccounted-for memory blocks, suggesting that the leaked memory is allocated within the Media SDK library.
The hardware platform I use in my tests is the Intel NUC6i3SYH kit, running Windows 7 Embedded x64. The video driver version I use today is 4481 (previously used 4463 and it showed the same results). Hardware details are shown in the System Analyzer log: 520815
In an attempt to isolate the problem, I ended up using sample_decode from the SDK samples to perform some tests. To my surprise, I found that sample_decode has the same memory leak (or at least a very similar behaviour) as my application.
Starting from a clean version of the SDK samples, I made a single modification to sample_decode to force the sample to play my H.264 file in an inifinite loop.
- Test video file: Big Buck Bunny trailer (https://peach.blender.org/download/), H.264, 1080p, 60fps (extracted the H.264 stream using Yamb)
- Command line: sample_decode.exe h264 -i bbb_sunflower_1080p.h264 -r
I built the sample for x86 and x64. Both versions yield the same behaviour during my tests. Using the above settings, the decoder sample slowly leaks memory over time at a rate of about 13-15MB/hour.
Do you have any ideas or leads on what might explain this? Is it a known issue currently being investigated?
I tried using the tracer tool in hope it might provide some insight, but while I can launch the tracer and start logging, it refuses to log anything (a .tracker file is created with the settings I selected, but the log file is never created).
Similar issue has been reported by some of our other customer as well. We have root cause the issue and working on hot fix. In the meantime, workaround for this problem is to roll back to old driver i.e. 4300 in which you should not see this issue. We will be keep you posted once the engineering fix is available.
Hope it helps.