[gst-devel] RTP work

[Andy Wingo]

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


-- 
Wim Taymans <wim at fluendo.com>