[Bug 761947] rtpbasepayload: rtpbasedepayload: Add source-info property

[GStreamer (GNOME Bugzilla)]

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

Stian Selnes (stianse) <stian.selnes at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stian.selnes at gmail.com

--- Comment #3 from Stian Selnes (stianse) <stian.selnes at gmail.com> ---
Let be elaborate a bit on the context that the proposed source-info feature
solves and the difference in regards to 762628 mentioned above.

GStreamer is currently lacking a way to propagate SSRC information from
incoming streams and add that as CSRC to an outgoing stream in order to attach
the sources that has contributed to a combined stream. Let me just copy-paste
our typical scenario which is also described in RFC 3550: "An example
application is audio conferencing where a mixer indicates all the talkers whose
speech was combined to produce the outgoing packet, allowing the receiver to
indicate the current talker, even though all the audio packets contain the same
SSRC identifier (that of the mixer)." The same is applicable to video of
course.

In order to achieve this functionality it's necessary to extract and propagate
the SSRC and CSRCs from the depayloader, forward this meta downstream and
possibly aggregate multiple metas into one, and finally have the payloader add
the contributing sources as CSRCs.

In addition to the case "depayloader ! mixer ! payloader" it's possible that
the application wants to add a specific CSRC on a stream. With the proposed
patch this can be achieved for example with a probe or element that adds meta
to the buffer before payloading.

The proposed patch adds a property to the depayloader that makes it add the
SSRC and CSRC as meta, and the payloader will add (if enabled) CSRCs to the
packets from this meta. The other patch mentioned above targets a different use
case. It can be used to pass SSRC and CSRC from the depayloader, but it makes
less sense to aggregate and payload a full RTP header meta like that. Thus, I
think a RTPSourceMeta is better suited to implement the missing CSRC
functionality.

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