1

I've been getting OOM errors after running my Gstreamer pipeline for long periods of time. Running on a Jetson-Xavier Devkit.

The smallest reproducible example: gst-launch-1.0 videotestsrc ! omxh265enc ! qtmux ! filesink location=test.mp4 -e

Memory before running:

sh-5.1# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0      0 5384300 307304 18665008    0    0     9    59   28   51  6  2 92  0  0

Memory after running 2 min:

sh-5.1# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
10  0      0 5151928 307560 18820992    0    0     9    59   29    1  6  2 92  0  0

Memory after running 10 min:

sh-5.1# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  0      0 4794396 308008 19138836    0    0     9    60   31    5  6  2 92  0  0

Memory after stopping:

sh-5.1# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 4836532 308040 19140984    0    0     9    60   31    5  6  2 92  0  0

RAM utilization never stops increasing relatively linearly, and the cache doesn't get freed when I stop the process.

This doesn't happen if I replace the filesink with a fakesink: gst-launch-1.0 videotestsrc ! omxh265enc ! qtmux ! fakesink

Memory before running:

sh-5.1# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 4836532 308040 19140984    0    0     9    60   31    5  6  2 92  0  0

Memory after running 2 min:

sh-5.1# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 4608692 308192 19141064    0    0     9    60   32    7  6  2 92  0  0

I have noticed the same issue with a splitmuxsink, when using mp4mux, and when switching out the omxh265enc, so I'm assuming there's something going on with the filesink?

Does anyone have any insight into this or know how to prevent gstreamer from using all my memory?

eden_debuggin
  • 11
  • 2

1 Answers1

0

Have you tried using nvv4l2h265enc instead?

Edit: I just used nvv4l2h265enc with filesink, and I'm seeing the same issue as you, very intersting.

Edit2: I think it's a matter on how commands like free or vmstat calculate virtual memory usage. For example the free command indeed shows less and less free memory overtime, however if you look at the used column, it does not increase overtime. Also using graphical monitor tools on the system like gnome system monitor, show that the memory does not increase in time.

Allan Navarro
  • 26
  • 3
  • Yes, I normally use nvv4l2h265enc and see this issue but wanted a minimal example without it because in the past there have been memory issues with it. I do see that the cache is increasing at a similar rate free is decreasing, but that doesn’t explain the OOMs. Could the application need more buffers/cache than is available on the system? – eden_debuggin Apr 11 '23 at 19:49