After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 720440 - rtpsession: internal sources are never removed
rtpsession: internal sources are never removed
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.3.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-12-14 00:30 UTC by Olivier Crête
Modified: 2014-05-14 14:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
rtpbin: Make it possible to set the initial caps using the caps in the request pad (1.87 KB, patch)
2013-12-14 00:55 UTC, Olivier Crête
rejected Details | Review

Description Olivier Crête 2013-12-14 00:30:09 UTC
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).
Comment 1 Olivier Crête 2013-12-14 00:55:12 UTC
Created attachment 264179 [details] [review]
rtpbin: Make it possible to set the initial caps using the caps in the request pad

This is a nasty workaround to set the initial SSRC, so if the application passes FIXED caps
to gst_element_request_pad(), then the SSRC from this caps will be used.
Comment 2 Olivier Crête 2013-12-14 01:16:20 UTC
Comment on attachment 264179 [details] [review]
rtpbin: Make it possible to set the initial caps using the caps in the request pad

Forget this, the app can just do a gst_pad_set_caps explicitly...
Comment 3 Sebastian Dröge (slomo) 2013-12-14 09:44:36 UTC
The app should not call gst_pad_set_caps() at all, especially as setting caps must only happen from streaming threads.

Other ways then the caps would be to have a property on the pads for the ssrc, or an action-signal that can be called to switch from one ssrc to another one. But via the caps seems acceptable too as in your patch.
Comment 4 Olivier Crête 2013-12-16 22:53:04 UTC
I'm not a big fan of having gst_element_request_pad() take fixed caps in that specific use-case, while this is normally not a requirement. This is why I dislike this solution. In this case, we call gst_pad_set_caps() before linking the pad, but I agree it's not an amazing solution. Having a property or an action signal might be better.. but this again forces the app to set the SSRC twice. And it doesn't solve the problem of timing out internal sources. Maybe we can treat the internal source that is in the current caps as a special one that doesn't time out and let the rest time out? Wim ?
Comment 5 Wim Taymans 2013-12-17 14:36:24 UTC
The internal sources should timeout as well, there is check to disallow that currently but we should remove the check now that the SSRCs are all dynamic.
Comment 7 George Kiagiadakis 2014-01-16 19:28:11 UTC
Ping? Is there any issue with these patches in my session-fixes branch, or can they be commited?
Comment 8 Sebastian Dröge (slomo) 2014-02-04 11:42:46 UTC
(In reply to comment #7)
> Ping? Is there any issue with these patches in my session-fixes branch, or can
> they be commited?

Did you consider comment 5?


Wim, anything blocking this?
Comment 9 Olivier Crête 2014-05-03 15:54:14 UTC
Wim: re-ping here ?
Comment 10 Wim Taymans 2014-05-14 13:45:14 UTC
I'll have a look at it soon
Comment 11 Wim Taymans 2014-05-14 14:25:23 UTC
commit b19c830a1c60c7e2f94007ece6f00c6929f7e80d
Author: George Kiagiadakis <george.kiagiadakis@collabora.com>
Date:   Fri Dec 27 11:55:18 2013 +0200

    tests/check: rtpsession: test internal sources timing out

commit 7e2138794f6c41def1d46a198871e30e4ef4c8fe
Author: George Kiagiadakis <george.kiagiadakis@collabora.com>
Date:   Thu Dec 26 17:30:42 2013 +0200

    rtpsession: remove unused if branch
    
    1) sources that have sent BYE in the past cannot be senders, since
    they would have timed out to being receivers in the meantime...
    2) sources that have sent BYE are now being removed earlier inside
    this function

commit 85d4c031d456b21b9e9e8c79f373d1161d45013d
Author: George Kiagiadakis <george.kiagiadakis@collabora.com>
Date:   Thu Dec 26 17:29:42 2013 +0200

    rtpsession: cleanup sources that have sent BYE

commit 7d7840cc4a73c53f10d8fb1979271787019f24f0
Author: George Kiagiadakis <george.kiagiadakis@collabora.com>
Date:   Thu Dec 26 17:24:51 2013 +0200

    rtpsession: unify nested if clauses

commit 0e6a31411bf2fd8ceb3d5c51f226a2003dfb204b
Author: George Kiagiadakis <george.kiagiadakis@collabora.com>
Date:   Thu Dec 26 17:21:44 2013 +0200

    rtpsession: timeout internal sources that are inactive for a long time and send BYE