[gst-devel] RTP work

[Zaheer Abbas Merali]

On Mon, 2005-04-04 at 13:24 +0200, Andy Wingo wrote:
> Hi,
> 
> Wim's mail server is still borked. Here's a message from him regarding
> RTP.
> 
> Subject: Re: [gst-devel] The Future of RTP
> From: Wim Taymans <wim at fluendo.com>
> 
> On Sun, 2005-04-03 at 23:46 +0500, Zeeshan Ali wrote:
> 
> > Wim,
> >    I have heard through (un)reliable sources that you have recently
> > thought out some nice ideas regarding all this. Would you like to
> > share them with us?
> 
> Heh, well, I just starting to look at it last week..
> I've been looking at various implementations of RTP libraries, and
> various plugins. 
> 
> - gst-plugins CVS
>    - gst/udp, gst/rtp
>    - separates out rtp packetizing and sending over udp in separate
>      plugins.
>    - does not use any library, copies code from Gnome-o-Phone for
>      generating valid RTP packets.
>    - no RTCP in the plugins.
> 
> - gst-sandbox rtpdec
>    - no encoding/sending
>    - does RTCP client side reports
>    - no decoding of packets, no handlers are implemented AFAICS
> 
> - farsight plugins
> http://cvs.sourceforge.net/viewcvs.py/farsight/gst-plugins/
>    - decoding/encoding
>    - uses jrtplib
>    - does RTCP transparently by jrtplib
>    - moves some RTP encoding to plugins (R263)
>    - also bug #168325
> 
> I'm currently in favour of a lib like libjrtp that sends and receives
> the RTCP reports transparently.
> 
> As for the formatting of the RTP packets there are different
> possiblities going from using separate elements to a tightly integrated
> solution in the encoders/decoders.
> 
> Some considerations:
> 
>  - handling of marker bit (use a buffer flag?) I have seen events too
>    to signal packet boundaries.
>  - some RTP payloads need to be generated/parsed in the
>    encoders/decoders (mp3..)  
>  - RTCP messages to influence encoding (quality, retransmission, ...)
>    do we use events to signal the encoders? do we adjust the encoding
>    for all clients or per client?
>  - RTP retransmission, different options again, integrated in the
>    encoder or keep a buffer in the sink for all clients.
> 
> I think the farsight plugins are the most promising at this point, they
> use a good and complete library and do both encoding/decoding. 
> 
> I would go for a simple rtpsink plugin first where the rtp encoding is
> done in separate elements then see where we can go from there. 
> 
> Any RTSP/SDP/.. should not be done by the rtp sink but by a separate
> element or the application. We eventually need the element to provide
> the rtsp:// uri handler to make it work in totem. The element would
> setup the rtpsrc and configure it using the session properties. Just
> some very rough thoughts.
> 
> Ideas, comments?
> 
> Wim
> 
> 

Hey Wim

I agree wrt to using the farsight guys' work, tho i dont like using a
buffer flag to mark packet boundary.

You have touched on some good points wrt per client and all clients.
Thats important for the streaming server use case, and in that use case
any retransmission and congestion control has to be done per client.
You cannot have all clients handled the same.

WRT RTSP/SDP I fully agree with you, it should be done by say a
specialised bin.  I dont see why it should be punted to the application
if it can be done nicely in a bin without impacting the rtp-related
elements.


-- 
Zaheer Abbas Merali <zaheerabbas at merali.org>