Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory Leak due to RTCP #28

Open
remmius opened this issue Apr 6, 2020 · 1 comment
Open

Memory Leak due to RTCP #28

remmius opened this issue Apr 6, 2020 · 1 comment

Comments

@remmius
Copy link

remmius commented Apr 6, 2020

Hi,
i played recently a bit with the plugin-element - great tool.
Unfortunately, there seems to be a memory leak due to the exchange of RTCP-packages. The RAM of the sender increases roughly by ~10MB per ~10 minutes starting right from the beginning. The receiver takes some time 2-5min in my case, and then also starts to build up RAM and CPU consumption (up to 100% CPU after an hour).
Hints:

  • If I deactivate sending RTCP from the sender, the memory leakage in the reciever stops.
  • In the debug-output (GST_DEBUG=rtpsession:5) on the sender of the rr, I saw that the second sdes entry (data=gstreamer) has been disappeared, if a gscreamrx-element is used in the reciever.
  • If i remove the gscreamtx element, the memory consumption still increases on the tx-side. If i remove both gscream elements the memory leak stops.
  • If the RTCP-buffer is freed in the "on_recieving_rtcp"-callback, the memory-leak stops. However, with the downside, that the rtpsession does not have the rtcp-feedback available anymore either.
  • I run on localhost->localhost with GStreamer 1.14.5 and the build based on the master branch.

Thanks for your work!

Note: Please also update the file ScreamRx.h in the gst-plugin folder. It does not match with referenced ScreamRx.cpp in the main-folder any more. It is difficult to determine the latest version among multiple versions of the same file with same name in different locations.

@remmius
Copy link
Author

remmius commented Jul 26, 2020

Pipeline to reproduce the issue on localhost with 1 computer.
Sender:

  • gst-launch-1.0 rtpbin name=rtpbin ! videotestsrc is-live=true ! timeoverlay ! video/x-raw,width=640,height=480, framerate=30/1 ! videoconvert ! x264enc name=video tune=zerolatency ! rtph264pay ! 'application/x-rtp, payload=(int)96' ! gscreamtx media-src=0 ! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0 ! udpsink host=127.0.0.1 port=7878 rtpbin.send_rtcp_src_0 ! 'application/x-rtcp' ! tcpclientsink host=127.0.0.1 port=5002 tcpclientsrc host=127.0.0.1 port=5002 ! 'application/x-rtcp' ! rtpbin.recv_rtcp_sink_0
    Receiver:
  • gst-launch-1.0 rtpbin name=rtpbin ! udpsrc port=7878 ! 'application/x-rtp, encoding-name=(string)H264, payload=(int)96' ! gscreamrx ! application/x-rtp,media=video,clock-rate=90000,encoding-name=H264 ! rtpbin.send_rtp_sink_0 rtpbin. ! rtph264depay ! queue ! avdec_h264 ! xvimagesink sync=false tcpserversrc port=5002 ! 'application/x-rtcp' ! rtpbin.recv_rtcp_sink_0 rtpbin.send_rtcp_src_0 ! 'application/x-rtcp' ! tcpserversink port=5002 host=127.0.0.1 sync=false async=false

As the rtcp-feedback is done via a tcp-connection, it is necessary to start the receiver side before the sender side. However, with a tcp-connection it was much easier to make it running regarding the ports/nat...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant