[gst-devel] RTP Client sussystem design.

[Ramón García]

Hi.  This is the design of the GStreamer RTP handling
that Angle and me are writting. This is a general rtp
element that can work with any kind of data.

This design is a draft. Suggestions are welcome.

The typical pipeline (threads omitted for clarity)
will be

udpsrc udpsrc-control ! rtp-parser ! rtp-vorbis !
vorbis-decode ! osssink.

First, two elements, get data from the network and
feed it to rtp-parser.

Each packet of data arrives at udpsrc. Then rtp-parser
removes the rtp header and places a timestamp in the
buffer, from the timestamp in the RTP header. In
addition it puts in the caps of the output pad, the
type corresponding as specified in the RTP header.  As
the RTP header informs of the datatype by a "payload
type byte", the rtp-parser element has to map it to
the actual type. The mapping is sometimes dynamic and
has to be known through other means different than
RTP. Thus for this purpose the element provides a
property that is a GHashTable of payload bytes to
types.  Then the packet goes to an element that is
specific to RTP and to the codec. That element does
processing of RTP payload data that is specific to the
codec.  Finally the data goes to the decoder and then
to the sound card. The advandge of this design is the
the choice of elements can be automatic. That is, the
following pipeline should work:

udpsrc udpsrc-control ! rtp-parse ! spider ! osssink

rtp-parse puts the correct type in caps, and that
helps spider to link the next element and so on.

That is all for data flow. Now control.

The udpsrc-control receives control events from the
server. It delivers the packets, as is, to the
rtp-parser. The rtp-parser gets the packets and takes
appropiate action. Sometimes, the packets are passed
down to the pipeline (for instance, a packet
specifying the decoding dictionary of the vorbis
decoder).

In addition, an RTP client must send control packets
to the server. For example, for starting and closing
connection. This is obviously essential in the unicast
case, and is required by RFCs 1889 and 3550 even in
the multicast case. In addition, statistics of packet
loss must be delivered to the server to comply with
that RFCs. The rtp-parser sends rtp control packets as
events to the udpsrc-control, which delivers them to
the server.

It is debatable whether it is a good thing to split
udpsrc and udpsrc-control in two different elements.

A posible modification is that instead of
udpsrc-control, use a single udp element that has a
src pad and a dest pad. What do you think?

Another posible change is that instead of having a rtp
server element and rtp client element, we could have
an element that servers both purposes. This is
necessary for applications that use the same channel
for sending in both directions, such as voice over IP.

Ramon


___________________________________________________
Yahoo! Messenger - Nueva versión GRATIS
Super Webcam, voz, caritas animadas, y más...
http://messenger.yahoo.es