scream icon indicating copy to clipboard operation
scream copied to clipboard

Memory Leak due to RTCP

Open remmius opened this issue 4 years ago • 1 comments

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 avatar Apr 06 '20 19:04 remmius

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...

remmius avatar Jul 26 '20 18:07 remmius