gstrtpsession

gstrtpsession — an RTP session manager

Synopsis




                    GstRTPSession;

Object Hierarchy


  GObject
   +----GstObject
         +----GstElement
               +----GstRTPSession

Signals


  "clear-pt-map"                                   : Action
  "request-pt-map"                                 : Run Last

Description

The RTP session manager models one participant with a unique SSRC in an RTP session. This session can be used to send and receive RTP and RTCP packets. Based on what REQUEST pads are requested from the session manager, specific functionality can be activated.

The session manager currently implements RFC 3550 including:

  • RTP packet validation based on consecutive sequence numbers.

  • Maintainance of the SSRC participant database.

  • Keeping per participant statistics based on received RTCP packets.

  • Scheduling of RR/SR RTCP packets.

The gstrtpsession will not demux packets based on SSRC or payload type, nor will it correct for packet reordering and jitter. Use gstrtpssrcdemux, gstrtpptdemux and gstrtpjitterbuffer in addition to gstrtpsession to perform these tasks. It is usually a good idea to use gstrtpbin, which combines all these features in one element.

To use gstrtpsession as an RTP receiver, request a recv_rtp_sink pad, which will automatically create recv_rtp_src pad. Data received on the recv_rtp_sink pad will be processed in the session and after being validated forwarded on the recv_rtp_src pad.

To also use gstrtpsession as an RTCP receiver, request a recv_rtcp_sink pad, which will automatically create a sync_src pad. Packets received on the RTCP pad will be used by the session manager to update the stats and database of the other participants. SR packets will be forwarded on the sync_src pad so that they can be used to perform inter-stream synchronisation when needed.

If you want the session manager to generate and send RTCP packets, request the send_rtcp_src pad. Packet pushed on this pad contain SR/RR RTCP reports that should be sent to all participants in the session.

To use gstrtpsession as a sender, request a send_rtp_sink pad, which will automatically create a send_rtp_src pad. The session manager will modify the SSRC in the RTP packets to its own SSRC and wil forward the packets on the send_rtp_src pad after updating its internal state.

The session manager needs the clock-rate of the payload types it is handling and will signal the GstRTPSession::request-pt-map signal when it needs such a mapping. One can clear the cached values with the GstRTPSession::clear-pt-map signal.

Example pipelines

gst-launch udpsrc port=5000 caps="application/x-rtp, ..." ! .recv_rtp_sink gstrtpsession .recv_rtp_src ! rtptheoradepay ! theoradec ! xvimagesink

Receive theora RTP packets from port 5000 and send them to the depayloader, decoder and display. Note that the application/x-rtp caps on udpsrc should be configured based on some negotiation process such as RTSP for this pipeline to work correctly.

gst-launch udpsrc port=5000 caps="application/x-rtp, ..." ! .recv_rtp_sink gstrtpsession name=session \
       .recv_rtp_src ! rtptheoradepay ! theoradec ! xvimagesink \
    udpsrc port=5001 caps="application/x-rtcp" ! session.recv_rtcp_sink

Receive theora RTP packets from port 5000 and send them to the depayloader, decoder and display. Receive RTCP packets from port 5001 and process them in the session manager. Note that the application/x-rtp caps on udpsrc should be configured based on some negotiation process such as RTSP for this pipeline to work correctly.

gst-launch videotestsrc ! theoraenc ! rtptheorapay ! .send_rtp_sink gstrtpsession .send_rtp_src ! udpsink port=5000

Send theora RTP packets through the session manager and out on UDP port 5000.

gst-launch videotestsrc ! theoraenc ! rtptheorapay ! .send_rtp_sink gstrtpsession name=session .send_rtp_src \
    ! udpsink port=5000  session.send_rtcp_src ! udpsink port=5001

Send theora RTP packets through the session manager and out on UDP port 5000. Send RTCP packets on port 5001. Note that this pipeline will not preroll correctly because the second udpsink will not preroll correctly (no RTCP packets are sent in the PAUSED state). Applications should manually set and keep (see #gst_element_set_locked_state()) the RTCP udpsink to the PLAYING state.

Last reviewed on 2007-05-28 (0.10.5)

Element Information

plugin gstrtpmanager
author Wim Taymans <wim@fluendo.com>
class Filter/Network/RTP

Details

GstRTPSession

typedef struct _GstRTPSession GstRTPSession;

Signal Details

The "clear-pt-map" signal

void                user_function                      (GstRTPSession *sess,
                                                        gpointer       user_data)      : Action

Clear the cached pt-maps requested with GstRTPSession::request-pt-map.

sess : the object which received the signal
user_data : user data set when the signal handler was connected.

The "request-pt-map" signal

GstCaps*            user_function                      (GstRTPSession *sess,
                                                        guint          pt,
                                                        gpointer       user_data)      : Run Last

Request the payload type as GstCaps for pt.

sess : the object which received the signal
pt : the pt
user_data : user data set when the signal handler was connected.

See Also

gstrtpjitterbuffer, gstrtpbin, gstrtpptdemux, gstrtpssrcdemux