[FFmpeg-user] High memory usage when merging videos

[Jonathan Girven]

> The changes I am working on would fix the "bufferqueue overflow,
> dropping" problems that occur with slightly unbalanced streams, for
> example audio streams with tiny frames where you can get a hundred or so
> frames in one go.

Thanks for clarifying that Nicolas.

> But it would not fix the really unbalanced cases, because nothing can.

Are you thinking that the processing task I am trying to perform is
simply too much for the device I am using? That might well be the
answer.

Naively I thought that, assuming the device could hold some number of
dependent frames in memory, a less powerful device would only take
more time to process a video, not trigger the OS to kill it. Obviously
it is much more complicated than that, but still << 1GB RAM on a Moto
G. FFmpeg using all the memory available to it isn't necessarily a bad
thing. My problem is Android interpreting that as a reason to kill the
task.

I have tried many similar commands to narrow down what is happening.
Just re-encoding a 2 minute video on the device doesn't get killed by
the OS, e.g:

ffmpeg -i input.mp4 -vcodec libx264 -preset faster output.mp4

Even though that is significantly more video and takes more time than
the previously mentioned command. Similarly for trimming with "-ss"
and "-t". Therefore my complex filter usage must be related to the OS
killing the task. For both commands, FFmpeg quotes the speed at ~0.2x,
so the processing time must be limited by the decoding or encoding
rate.

I am still working on trying to get something more specific than that,
but it is difficult because running the same command twice does not
consistently get killed or succeed. I suppose the first iteration
might succeed but leave resources allocated (in my app or FFmpeg), so
the second iteration is killed. For reference, the memory monitor of
my app hovers around 40-60MB (but does not show FFmpeg's memory
usage).

Always open to new suggestions! Or perhaps hiring an FFmpeg developer
is the way forward.
Thanks,
Jon.