Gstreamer customisation for meta-fsl-bsp-release

[taruntejkanakam]

Hi,

I have a Yocto setup using https://source.codeaurora.org/external/imx/imx-manifest/tree/imx-4.9.88-2.0.0_ga.xml?h=imx-linux-roc...

On top of this, using a custom layer, I used gstreamer 1.14.2 recipes downloaded from http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-multimedia/gstreamer

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 = " \     http://gstreamer.freedesktop.org/src/gst-plugins-bad/gst-plugins-bad-${PV}.tar.xz \ " 

GST1.0-PLUGINS-BAD_SRC ?= "gitsm://source.codeaurora.org/external/imx/gst-plugins-bad.git;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.

Note:

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://source.codeaurora.org/external/imx/gst-plugins-bad.git. 

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.

Thanks

[marcomadrigal]

Hi Taruntej,

Could you post your pipeline or a similar one that presents the same issue? Are you using any specific hardware unit or capture subsystem? Most of i.MX based plugins dead with special memory allocated in the system and used it on a buffer pool to about subsequent memory allocation requests. Those buffers are specially market and are quite different from normal Gstreamer buffers so in most of the cases you need to explicitly make your plugins to work and understand this memory model which might include the creation of special allocators for the plugins.

In any case, it is quite to determine what is going on with the data provided, however if you are looking for the changes made on the NXP's branch you can just check out the branch and take a look to the differences:

git clone -b MM_04.03.05_1804_L4.9.88_MX7ULP_GA https://source.codeaurora.org/external/imx/gst-plugins-bad.git

Hope this helps.

Best Regards,

Marco

http://www.ridgerun.com

[taruntejkanakam]

Thanks for the response Marco. 

Please see the pipeline template below:

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

I am not using any specific hardware.It is rtspsrc to splitmuxsink.

I think the difference in gstreamer source is not the reason for this issue as I am able to see the issue in both original yocto as well as freescale customised one after few more tests for longer duration.

Please note that I am seeing the issue when we are running 4 or more pipelines simultaneously. When we stick with just 3 pipelines the CPU usage and Memory usage consistent after even almost 33 hours of running. 

It could be that the splimuxsink is very heavy the iMX6UL core. We would need a proper method to confirm this point.

[igorpadykov]

Hi Taruntej

issue may be caused by differencies described on

Difference between "vpudec" and "imxvpudec"? 

questions with gstreamer-imx also can be posted on
Issues · Freescale/gstreamer-imx · GitHub 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[taruntejkanakam]

Hi igor,

Thanks for response.

I am not using vpudec or imxvpudec in my pipeline. Do you think they are being internally used by other elements?

Here is my pipeline template:

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

Thanks for pointing me to GitHub. As per the latest observations, the issue is seen in both original gstreamer as well freescale customised gstreamer

[igorpadykov]

Hi Taruntej

my answer was related to differencies between two plugings described on

suggested link, not exactly usage  vpudec or imxvpudec.

Best regards
igor