AnsweredAssumed Answered

Gstreamer customisation for meta-fsl-bsp-release

Question asked by Taruntej Kanakamalla on Sep 30, 2018
Latest reply on Oct 4, 2018 by igorpadykov
On top of this, using a custom layer, I used gstreamer 1.14.2 recipes downloaded from
So I have successfully built gstreamer1.14.2 for imx6ul using these recipes. 
But I have observed that upon running 4 or more simultaneous pipelines the RAM usage grows very rapidly and within 30 minutes OOM_killer gets invoked and kills one of the pipelines.
When I removed the custom layer and reverted the gstreamer to 1.12.2 (whose source is taken from freescale custom gstreamer repo instead of original gstreamer repo) I do not see any excess Memory usage or OOM issues even after running for 24 hours.
# Use i.MX fork of GST for customizations
SRC_URI_remove_imx = " \${PV}.tar.xz \ " 
GST1.0-PLUGINS-BAD_SRC ?= "gitsm://;protocol=https"
SRCBRANCH = "MM_04.03.05_1804_L4.9.88_MX7ULP_GA" 
SRC_URI_append_imx = " \     ${GST1.0-PLUGINS-BAD_SRC};branch=${SRCBRANCH} \ "
Since the gstreamer recipes present in meta-fsl-bsp-release are pointing to different source instead of the original gstreamer sources repo, what are the major changes done in the gstreamer for iMX which is preventing the Memory issue or Out Of Memory situations?
I am not using any imx specific gstreamer elements. Only general elements like rtspsrc, h264parse, h264depay, splitmuxsink etc.
I do not think this issue is related to version difference as this issue is not seen on Ubuntu x86 which is running 1.14.x
I have added the same query in meta-freescale mailing list (see here), awaiting response.
Update (Oct 03, 2018):
Upon further tests for longer duration, it is observed that the issue is seen to happen even on 1.12.2 whose source is fetched from gitsm:// 
So broadly speaking, this issue is not specific to any particular version of gstreamer. It is seen only when more than 3 pipelines run simultaneously. Below is a the pipeline we are using:
gst-launch-1.0 -e rtspsrc location="rtsp://<user>:<pass>@<IP_ADDR/RSTP_API>" name =d ! rtph264depay ! h264parse  ! splitmuxsink name = mux location=a1_video%02d.mp4 max-size-time=10000000000 max-files=3
We dont see any issue so far when we run three pipelines simultaneously. Add one more pipeline and the Used RAM grows very rapidly and within 15-20 minutes OOM_Killer gets invoked.