[gst-devel] GstRtpBin Internals

[Marco Ballesio]

Hi,

On Mon, Nov 15, 2010 at 10:11 PM, Wes Miller <wmiller at sdr.com> wrote:
> Hi All,
>
> I have a lovely gstrtpbin pipe that sends and receives audio. It also sends
> and receives RTCP packets but I am not sure just what that means and what to
> do with them..
>
> I am trying to use the same pipeline on two machines to make what amounts to
> a two way always live intercom. I am using "1" for my session number.
>
>
>                                                  .-------.
>  ......... udpsrc port 5002---> recv_rtp_sink_1  |  gst  | recv_rtp_src_1
> -----> ... speakers
>  : _______ udpsrc port 5007---> recv_rtcp_sink_1 |  rtp  |
>  : |                                             |  bin  |
>  : |          microphone ... --> send_rtp_sink_1 |  # 1  | send_rtp_src_1
> ---> udpsink port 5002 ........
>  : |                                             |       | send_rtcp_src_1
> --> udpsink port 5003 ---.  /
>  : |                                             '-------'
> /  /
>  : |
> /  /
>  : |
> /  /
>  : |
> .________________________________________________________________________________________/
> /
>  : |   |
> ........................................................................................./
>  : |   | :
>  : |   | :
>  : |   | :                                       .-------.
>  : |   | :. udpsrc port 5002---> recv_rtp_sink_1 |  gst  | recv_rtp_src_1
> -----> ... speakers
>  : |   |___ udpsrc port 5007 -> recv_rtcp_sink_1 |  rtp  |
>  : |                                             |  bin  |
>  : |          microphone ... --> send_rtp_sink_1 |  # 2  | send_rtcp_src_1
> --> udpsink port 5003 ______
>  : |                                             |       | send_rtp_src_1
> ---> udpsink port 5002 __   /
>  : |                                             '-------'
> /  /
>  : |
> /  /
>  :
> |____________________________________________________________________________________________/
> /
>
> :................................................................................................/
>
>
>
>
> If I connect my send_rtcp_src_1 (on GstRtpBin #1) pad's output through the
> network (udpsink to udpsrc) and feed it in to the recv_rtvp_sink_1 pad on on
> GstRtpBin #2, what will GstRtpBin #2 do with that information? DOes it
> understand that it describes the RTP data coming into recv_rtp_sink_1 and
> automatically adjust the received stream?

RTCP info are handled "automatically" (see below) when the value of
"n" is the same for recv_rtcp_sink_n and recv_rtp_sink_n (and
similarly for the sender side).

> Or does it just map the
> information back out (I guess) recv_rtcp_src_1 where I can process it..
>

Both RTP sending and receiving side generate, respectively, Sender
Reports and Receiver Reports when needed, according to RFC 1889
section 6. On the side receiving an RTCP message, a signal of type
"on-ssrc-active" is emitted. Data conveyed from it is then accessible
through the "stats" property of the RTPSource element bound to the
stream (accessible through the RTPSession element within the
gstrtpbin) and remains accessible until the next RTCP message arrives.

When an RTCP packet containing SDES info is received, the additional
signal "on-ssrc-sdes"
is originated and the "sdes" property of the related rtpsession
(structure of type "application/x-rtp-source-sdes") is updated
accordingly. As far as I understood SDES messages are sent together
with the first RTCP message associated with a stream and you can
modify SDES info from the sender side through the "sdes" property.

BYE messages are emitted by the sender's session henever an EOS is
received by it or the SSRC associated to a stream changes after e.g. a
collision. The signal "on-bye-ssrc" is emitted upon reception and
"on-bye-timeout" when the BYE message has timed out.

Application-specific (APP) messages are not handled at all (it would
be good to add at some point at least a generic handling) and no
support is available for feedback (FB) ones, even though handling
functions are appearing in gstrtcpbuffer, so probably they'll be
supported soon.

> If I am to process it, do I need to hook the stream to an identity or
> appsink to get at its contents and parse them into a form to be sent out as
> events to ... well, to who?..

I guess that in a generic enough app you don't need to handle the RTCP
sending side, while you'll have to hook on the signals and read the
properties of above from the receiving side. No further handling than
the one described above appears to be done from within GStreamer (e.g.
encoder settings are not modified when an RR is received), so you'll
need to implement those into your app if you need to.

>
> Any help would be appreciated. I have spent hours googling this and finding
> little nad still more time reading the old gstreamer fora. Lots of
> interesting but not directly related discussion..

Often the answer is closer than what we think ;) . You can find all of
the info I've reported above (and more) directly from the (gstrtpbin,
rtpsession, rtpsource) sources in gst-plugins good and gstrtcpbuffer
in gst-plugins-base. cscope (and grep) are your friends.

Regards

>
> Warmly,.
>
> Wes.
>
> ________________________________
> View this message in context: GstRtpBin Internals
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>