[gst-devel] RTP Client sussystem design.

[Angel Carpintero]

On Thu, 4 Sep 2003 13:23:26 +0200 (CEST)
Ramón García <ramon_garcia_f at yahoo.com> wrote:

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

 s/Angle/Angel :)
 
> 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.

  I guess that udpsrc-control should be replaced by rtp-control , because
 this elemet is related to rtp control ( rtcp packets , BYE for instance ) 
 and it shouldn't be  binded to specific transport protocol , it should be 
 insolate to protocol instead.
 
> 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.

 Cool , i'm agree with data flow. Great work Ramón ! :)


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

  Do you mean that udpsrc is listening for data (rtp packets) 
 and udpsrc-control for control ( rtcp packets ) ?
 
> 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.

 i think udpsrc should be independent of rtp so udpsrc-control
 or rtp-control must be a different element.
  
> 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.

 Well this could be implementing in application level using
 both elements , so IMHO it's not necesary at all.
 

 Adding some comments to this draft about rtp send part :

 Following the dessing on client side that you've proposed , a 
 possible pipeline for rtp sending should be something like this :

 v4lsrc ! mpeg4encode ! rtp-mpeg4enc ! rtp-parse ! rtp-control ! udpsink

  Where rtp-mpeg4enc should create the payload packets for mpeg4 payload time
 and push them to rtp-parse that will build the rtp packet adding the rtp header
 and creating the needed control information to push to rtp-control , then rtp-control
 will be able to build the rtcp packets .

 That's a quick approach , so i hope you'll have a lot of comments about it .


> Ramon
> 
>
> ___________________________________________________
> Yahoo! Messenger - Nueva versión GRATIS
> Super Webcam, voz, caritas animadas, y más...
> http://messenger.yahoo.es
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel


-- 
Angel Carpintero - angel at e-group.org
_________________________________________________________

ELECTRONIC GROUP INTERACTIVE - www.electronic-group.com
World Trade Center, Moll de BARCELONA
Edificio Norte 4 Planta
08039 BARCELONA SPAIN
Tel :    +34 93 600 23 23  
Direct : +34 93 600 23 19
Fax :    +34 93 600 23 10
_________________________________________________________