[Bug 725630] New: gst-rtsp-server: memory leak after connecting/disconnecting repeatedly

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=725630
  GStreamer | gst-rtsp-server | git

           Summary: gst-rtsp-server: memory leak after
                    connecting/disconnecting repeatedly
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-rtsp-server
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: aleix at oblong.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=270859)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=270859)
client for test-launch sample

I'm investigating what it seems to be a gst-rtsp-server memory leak.

It can be reproduced with the test-launch example. This is what I run:

./test-launch "( videotestsrc ! capsfilter
caps=\"video/x-raw,width=1920,height=1080\" ! x264enc tune=zerolatency
speed-preset=ultrafast ! rtph264pay name=pay0 pt=96 )"

Then I have a really simple python script (attached) that creates as many
clients as desired (sequentially). 

./test-launch-client.py 100

Memory keeps slowly increasing indefinitely (just looking at htop).

I have tried valgrind multiple times, but right now it doesn't seem obvious to
me.

I have also tried a different encoder and payloader (theora) with the same
effects.

./test-launch "( videotestsrc ! capsfilter
caps=\"video/x-raw,width=1920,height=1080\" ! theoraenc ! rtptheorapay
name=pay0 pt=96 )"

With jpegenc and rtpjpegpay, looks much better.

May be I don't understand something correctly of what's going on (e.g.
regarding buffer pools).

I'll update the bug if I find something else.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.