[Bug 749581] rtpbasepayload: Try harder to reuse previously configured caps values and give more preference to anything set as properties

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=749581

--- Comment #7 from Olivier Crête <olivier.crete at ocrete.ca> ---
(In reply to Sebastian Dröge (slomo) from comment #6)> 
> Is this only a problem with the SSRC, or do the changes to the
> pt/seqnum/clockbase fields negotiation also look problematic to you?

Just ssrc, seqnum/clockbase are random (in Farstream) and pt is always fixed.

> > Suggestion to fix your problem, changing rtpsession to, for caps
> > negotiation, ignore the SSRC inside the packets and just take it from the
> > caps event, then return that in the caps query. I assume that should prevent
> > the rtprtxsend from interfering and causing useless renegotiations?
> 
> That should work, yes. That would mean that rtpsession is always proposing
> - a new SSRC if there was a collision
> - the SSRC from the property if it was set
> - the SSRC from the caps if there are caps and they contain an ssrc
> - a random SSRC
> 
> (whichever condition is true first).
> 
> Additionally rtpbasepayload would always prefer a downstream SSRC if there
> is one, which means that the property is completely ignored if downstream
> proposes an SSRC. So with rtpbin, the SSRC property on rtpbasepayload has
> absolutely no effect (as before the breaking change).
> 
> 
> Seems ok to you?

Seems ok to me. In 2.0, we can drop the ssrc property on rtpsession and control
everything from the payloaders !

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.