[Bug 720435] rtpbasepayload: Prefer downstream SSRC after collision if possible

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #8 from Wim Taymans <wim.taymans at gmail.com> 2013-12-18 13:49:48 UTC ---
(In reply to comment #4)

> As I said on the other bug, I'm not convinced sending multiple sender-side
> SSRCs over the same pad was the best idea.

Pro and cons of sending multiple sender over different pads into the same
session:

Pro:

 - Each sinkpad has its own SSRC caps field suggestion
 - possibility to EOS per sender SSRC

Con:

 - Need to change rtpsession to allow multiple request pads for send_rtp_sink,
need to add a unique number to each sender pad, it would break ABI/API. Can we
do it without problems (add new send_rtp_sink_%u, would it break things?)
 - Configuration of AUX elements (session or SSRC multiplexing) needs to be
done
in the AUX element because we would now always request multiple srcpads from
the sender AUX element, how do we link the srcpads to a session? It would need
something like src_%u_%u with ssrc number and session number to link to. The
AUX element should make different SSRCs for different sessions.
 - asymetric with receiver session until the ssrcdemux and jitterbuffer are
merged into session. Merging ssrcdemux and jitterbuffer into session might be
impossible because AUX receiver need to be placed before jitterbuffer.
 - how does the AUX receiver element work? it needs sink_%u_%u as well and
expect different SSRC for same sessions, same SSRC for different sessions.

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