[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 #6 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Olivier Crête from comment #4)
> It should default to the downstream recommendation. Farstream relies on this
> behavior, so we can just change the "internal-ssrc" property on rtpsession
> and have it propagated upstream.

Is this only a problem with the SSRC, or do the changes to the
pt/seqnum/clockbase fields negotiation also look problematic to you?

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

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