1

I'm using the Geraint Davies' MP4Demux to stream some previously encoded mp4 files.

In a past investigation I found that the MP4Demux allocates the memory for all the atoms on loading. For smaller files this works ok, but using a larger mp4 file (about 1.2GB) I get an out of memory error on IMediaControl::Run.

One option would be to rewrite/edit the mp4 demux to have a pool/circular buffer of memory and to only read the frames as they are needed/requested, but I'm wondering if there is a simpler solution e.g. like somehow increasing the memory that the DirectShow application can use (it is a 32-bit console application though).

Ralf
  • 9,405
  • 2
  • 28
  • 46
  • Did you, by any chance, try to use [my fork](https://github.com/roman380/gdcl.co.uk-mpeg4) of the demultiplexer? I remember that some allocations there could be better. My guess would be that some allocator simply has excessive number of buffers or buffers are too large. It would make sense to inspect the allocators first to see if there is something obvious to tune/fix. – Roman R. Aug 28 '15 at 09:29
  • Hi @RomanR., no, I used the last release of Geraint's. I had added some logging where the memory for the atoms was allocated and found that all the memory was allocated in the beginning (IIRC on loading the filter) but the out of memory error only occurs on IMediaControl::Run. IIRC deallocation only took place on unloading the filter. In that case, I don't think the DirectShow allocators come into play at all? – Ralf Aug 28 '15 at 09:42
  • Regular allocation takes place on Stopped -> Paused transition, which might be a part of `Run` call. Then problematic place could simply allocate a lot, but not fatally too much. Then further "normal" memory allocation such as by H.264 decoder, which also needs some RAM, fails and gets you the error. My point is that allocators are obvious thing to check first. – Roman R. Aug 28 '15 at 09:54
  • Ok, thanks for your input, much appreciated. I will investigate further. – Ralf Aug 28 '15 at 10:05
  • @RomanR. Please add your comment as an answer, after inspecting the allocator I see that that was indeed were the problem was. – Ralf Aug 28 '15 at 10:56

1 Answers1

2

Typical memory consumers in graphs are memory allocators. Leaving the underlying reasons aside, sometimes allocation is excessive: too many buffers and/or too large buffers. The allocation is typically taking place in stopped-to-paused transition, which might be a part of Run call (it is actually a part of Pause call, but if you call Run while stopped, there is implicit Pause call as well).

Whatever is the reason, allocators are first thing to check: pause the graph and review process private bytes, process virtual address consumption, allocator properties (GraphStudioNext and DirectShowSpy should together be able to do this), and check if it makes sense or it is grabbing too much.

Sometimes it simply can take the process too close to virtual address space limit and the failure is not immediate, but memory pressure makes something else fail shortly afterwards.

Roman R.
  • 68,205
  • 6
  • 94
  • 158