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 762213 - rtpmux: property should overrule both upstream and downstream
rtpmux: property should overrule both upstream and downstream
Status: RESOLVED DUPLICATE of bug 795162
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-02-17 18:53 UTC by Håvard Graff (hgr)
Modified: 2018-09-17 11:36 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
test and fix (7.31 KB, application/mbox)
2016-02-17 18:53 UTC, Håvard Graff (hgr) 		  Details
test and fix (7.31 KB, patch)
2016-02-17 18:53 UTC, Håvard Graff (hgr) 		none Details | Review

Description Håvard Graff (hgr) 2016-02-17 18:53:14 UTC 
Created attachment 321533 [details]
test and fix

After thinking more about this, it no longer makes sense to me that something should be able to overrule the ssrc that you have set as a property on rtpmux. Setting this property is to me saying: "THIS is what I want the ssrc to be".

Without this patch, we often found the ssrc we ended up using on the wire was different then the one we had asked for.
Comment 1 Håvard Graff (hgr) 2016-02-17 18:53:59 UTC 
Created attachment 321534 [details] [review]
test and fix
Comment 2 Olivier Crête 2016-05-15 09:44:52 UTC 
I think the idea is that the controlling property is in the rtpsession.. Because it's the one that has to be in control because it knows about SSRC collisions. Right now if we have rtp*pay ssrc=X ! rtpmux ssrc=Y ! rtpsession ssrc=Z, then the rtpsession one wins I think, if I understand what you're proposing, the rtpmux would win ?
Comment 3 Håvard Graff (hgr) 2016-05-15 20:09:38 UTC 
(In reply to Olivier Crête from comment #2)
> I think the idea is that the controlling property is in the rtpsession..
> Because it's the one that has to be in control because it knows about SSRC
> collisions. Right now if we have rtp*pay ssrc=X ! rtpmux ssrc=Y ! rtpsession
> ssrc=Z, then the rtpsession one wins I think, if I understand what you're
> proposing, the rtpmux would win ?

Well... If you purposely specify three different properties with three different values you deserve to end up in a puddle of flow fail. It should be a given that rtpmux can override any ssrc specified upstream from it, since it has the power to combine several, and then obviously all upstream ones can't have their will/ssrc.


Now, the specific reason for this patch is that sometimes rtpbin will generate a sender-source for you, with a random ssrc. Now, if you *wish* to control what ssrc you are sending with, using a rtpmux, I would think that setting the ssrc-property would do just that, given that it is now the *only* ssrc-property that have been set. Without this patch this might not be the case, since you will instead be using a randomly generated ssrc from inside rtpbin. Now if you have the know-how (not so easy) to specify a ssrc directly on rtpsession, I would hope that you would not *also* try to specify a *different* ssrc on rtpmux...
Comment 4 Håvard Graff (hgr) 2018-09-17 11:36:31 UTC 
Now tracked in https://bugzilla.gnome.org/show_bug.cgi?id=795162

*** This bug has been marked as a duplicate of bug 795162 ***