[Bug 711087] rtpbin: Support Auxiliary streams

[GStreamer (bugzilla.gnome.org)]

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

Olivier Crete (Tester) <olivier.crete> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #27 from Olivier Crete (Tester) <olivier.crete at ocrete.ca> 2013-12-11 23:53:06 UTC ---
I had a chat with Wim on how this API should work.

1. - aux sender elements would have a static "sink" pad and n "src_%u" request
pads
   - aux receiver elements would have a static "src" pad and n "sink_%u"
request pads
2. The application would be responsible for requesting pads on the aux elements
elements before giving them to rtpbin
3. the %u in the request pad must correspond to the rtpbin session numbers of
the rtpsession that will be linked to them.

Multiple aux elements are handled by having a bin containing multiple aux
elements.


For the sender:

1. The application creates a sender aux element and configures it by requesting
the "src_%u" pads and setting properties
2. the application requests a send_rtp_sink_%u pad
3. rtpbin emits a "request-aux-sender" signal, the paremeter of the signal
would be the session number, the return value is the aux elements from step 1,
one of the pads of this aux pad must have a number corresponding to the session
number requested in step 2
4. rtpbin checks that no session currently exist with numbers matching the pads
from the aux element (so if it has pads src_1, src_2, src_3, it checks that
sessions 1, 2 and 3 don't exist). rtpbin also checks that the aux element has
no parent, etc. For any failure, it return NULL as the request pad.
5. rtpbin connects the aux element between the requested send_rtcp_src_%u and
the rtpsession, emits new sometimes pad for this new session.
6. rtpbin creates a new rtpsession for each extra pad on the aux element and
emits sometimes pads with matching numbers
7. rtpbin returns the pad requested in step 2

If the application tries to request the send_rtcp_sink_%u for any aux session,
NULL is returned.

For the receiver:

1. The application creates a sender aux element and configures it by requesting
the "sink_%u" pads and setting properties
2. the application requests a recv_rtp_sink_%u pad
3. rtpbin emits a "request-aux-receiver" signal, the paremeter of the signal
would be the session number, the return value is the aux elements from step 1,
one of the pads of this aux pad must have a number corresponding to the session
number requested in step 2
4. rtpbin checks that no session currently exist with numbers matching the pads
from the aux element (so if it has pads sink_1, sink_2, sink_3, it checks that
sessions 1, 2 and 3 don't exist). rtpbin also checks that the aux element has
no parent, etc. For any failure, it return NULL as the request pad.
5. rtpbin connects the aux element between rtpsession and ssrcdemux
6. rtpbin returns the pad requested in step 2
7. the application requested another recv_rtp_sink_%u pad for the aux session
configured on the aux element in step 1
8. rtpbin emits a "request-aux-receiver" signal, the paremeter of the signal
would be the session number, the return value is the aux elements from step 1
9. if the element is not the same, request_pad returns NULL
10. if the element is the same, check that it has a sink_%u pad matching the
one requested in step 7, otherwise also return NULL
11. create a new rtpsession, connect it to the aux element
12. return the request pad
13. for any other pad, goto 7

This API has the advantage that it's thread safe (two thread can request
different sessions and just try again if it returns NULL, there can be no
clash), etc.

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