[gst-devel] RTP Client sussystem design.

[Thomas Vander Stichele]

Hi,

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

Finally, cool pipelines that do stuff ! :) I'm guessing you missed the !
between udpsrc and the next one.  Personally I would drop all hyphens
though.  I agree with Angel on the next comment ...

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

... provided that there are actually useful situations where rtp-control
can be used with other transports (I thought it was UDP only ?)
> > 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 ! :)

+1, this would work out fine.  Someone will have to fix spider though :)

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

I need to read up more, but what sort of actions can
udpsrc-control/rtpsrc-control take on the data then ? I mean, can it
drop buffers, delay timestamps, ... ? What is it's function in general ?
 
> > 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.

I think it could be a matter of discussion whether or not to implement
the control element the way you describe (ie with it's own logic and udp
session handling), or in some more gstreamer-ish way (ie, with more
elements and outgoing data).  I can't say at all which of the two would
be best and for a first draft your approach looks fine.

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

I didn't understand this part.  How do you mean this to work ?


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

Just a question - wouldn't MPEG be generic enough once it is encoded and
framed so that we could easily have just one element for all MPEG data ?


Great work guys, finally something other than just media playback to
test GStreamer with :)

Thomas


Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
I was about to have my first sexual experience
and I wasn't even one of the players...
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/