[FFmpeg-user] FFMPEG run out of memory

[Cley Faye]

2016-05-09 1:06 GMT+02:00 ionut <ionut.raducanu at webland.ro>:
>
> Is this enough ? I need to say that I have a very large ( huge ) command
> that is being executed so a paste isn't good, and once I attaced to the
> output specification the '-report' and the report already had over 100k
> lines for 30s of output, while my total time is over 360.
>

​It would be better to post it anyway; text is not that heavy for e-mails :)
At least the full command and a big chunk of the output log would be good.
If you still think that the output log is too big, the most relevant parts
(in my opinion) is the beginning (everything from start to the beginning of
the transcode), the end (everything after the transcode progress until the
very end), and if something funny happens in the middle, everything
slightly before and slightly after, even lines containing supposedly known
informations: it is good to know that the program also know these.
In your case, it is most likely that ffmpeg output *something* before
crashing.​ And in any case, worst scenario is it's too much for anyone to
look at.


I also have some suggestions that might or might not be easy to implement
in your solution, that might (emphasis on "might"​) lower the memory usage,
in case it is the real culprit here. Again, note that my experience with
ffmpeg is mainly on the "I use it and it just work" side, so there:

 - If you only want no sound, maybe just not generating a soundtrack could
be a good idea

 - The background input have no size specified (default is 320x240 but I
doubt it suits you), and maybe setting the framerate inside the filter
instead of using -r can improve things (I also have a preference of putting
these things inside the same filter expression as the rest, which might or
might not help ffmpeg to better understand the filtergraph). By setting at
least the size I suppose you could remove some scale...

​- For each image input, since you feed them in a complex filter it might
be possible (quick testing says yes, but I don't know your whole situation)
to not have each images at 30 FPS. When I do some sort of collage, I end up
having each image having a rate of 1/duration, effectively making them a 1
frame source. The filtering ends up producing a video at the right
framerate so it's not an issue, but it might help.

​Note that none of these "advices" is likely to help for your warning
message, ​only with memory usage. Also, the third trick did yield a smaller
memory footprint (for a 1minute video and a single image source, going from
231MB to 226MB) alongside a *serious* boost in speed (40seconds to
16seconds). If anything, it could help your command to crash faster ;)