Memory leak when writing camera live-stream to file
I am recording the video stream of a camera in segments of 60 seconds using the following pipeline:
gst-launch-1.0
rtspsrc location="rtsp://10.0.1.13/Streaming/Channels/201?transportmode=unicast" protocols=4 buffer-mode=0 ! rtph264depay ! video/x-h264,framerate=20/1,width=704,height=576 ! h264parse ! queue ! splitmuxsink muxer="matroskamux" max-size-time=60000000000 location="/mnt/persistent/test-pipe/$( date '+%F %T' )-cam3-1-%02d.mkv"
rtspsrc location="rtsp://10.0.1.13/Streaming/Channels/301?transportmode=unicast" protocols=4 buffer-mode=0 ! rtph264depay ! video/x-h264,framerate=20/1,width=704,height=576 ! h264parse ! queue ! splitmuxsink muxer="matroskamux" max-size-time=60000000000 location="/mnt/persistent/test-pipe/$( date '+%F %T' )-cam3-2-%02d.mkv"
rtspsrc location="rtsp://10.0.1.13/Streaming/Channels/401?transportmode=unicast" protocols=4 buffer-mode=0 ! rtph264depay ! video/x-h264,framerate=20/1,width=704,height=576 ! h264parse ! queue ! splitmuxsink muxer="matroskamux" max-size-time=60000000000 location="/mnt/persistent/test-pipe/$( date '+%F %T' )-cam3-3-%02d.mkv"
rtspsrc location="rtsp://10.0.1.13/Streaming/Channels/501?transportmode=unicast" protocols=4 buffer-mode=0 ! rtph264depay ! video/x-h264,framerate=20/1,width=704,height=576 ! h264parse ! queue ! splitmuxsink muxer="matroskamux" max-size-time=60000000000 location="/mnt/persistent/test-pipe/$( date '+%F %T' )-cam3-4-%02d.mkv"
Everything works fine so far and I have been able to run the pipe for multiple days without problems. Unfortunately at some point, there is a sudden increase of memory usage going from an initial ~20MB to over 500MB and rising.
I tried to locate the problem using the following environment settings:
GST_DEBUG=GST_TRACER:7 GST_TRACERS=leaks GST_DEBUG_FILE=/tmp/gst.log
but there were no logs indicating leaks.
I made some further tests and it seems that the behavior can be reproduced quicker, if the system is at high load. (e.g. by starting multiple sha1sum /dev/zero &
processes)
The attached valgrind analysis shows a lot of memory being allocated by the rtpjitterbuffer: massif.out.23925
86.89% (186,924,693B) 0x150C0894: pop_and_push_next (gstrtpjitterbuffer.c:3568)
Test environment:
- GStreamer: 1.16.0 - I also did a quick test with an older version (1.10.4) and had a similar behavior
- System: 64 Bit - Atom E3950 1.60GHz 4 Cores - 8 GB RAM