[Bug 720440] New: rtpsession: internal sources are never removed

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=720440
  GStreamer | gst-plugins-good | git

           Summary: rtpsession: internal sources are never removed
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: olivier.crete at ocrete.ca
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


If you have multiple internal sources (for example multiple senders), these
sources never time out. They time out of being a sender, but a "BYE" is never
sent and they keep on sending receiver reports.

A common case where this can happen is if you want to control which SSRC you
use to send, so you have a pipeline like rtpXXXpay ! application/x-rtp, ssrc=Z
! rtpbin. But you don't start sending from the very beginning, so at the first
timeout, rtpsession creates a new internal source with a random SSRC. When you
start sending, the application selected SSRC arrives at rtpbin, a new internal
source is create. So now we have 2 internal sources in the rtpsession, but it
never times out.

This leads me to think that we need a way to tell rtpsession when we want to
stop using a SSRC. Maybe some kind of partial-EOS custom downstream serialized
event ? Another option is to admit that we got the multiple-senders API wrong
and add a send_rtp_sink_%u_%u request pad on rtpbin/rtpsession and then only
send one SSRC per pad (and when the caps change, we know the SSRC is gone).

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