[gst-devel] RTP work
wingo at pobox.com
Mon Apr 4 04:24:25 CEST 2005
Wim's mail server is still borked. Here's a message from him regarding
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:
> 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
- gst-plugins CVS
- gst/udp, gst/rtp
- separates out rtp packetizing and sending over udp in separate
- 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
- 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.
- 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
- 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.
Wim Taymans <wim at fluendo.com>
More information about the gstreamer-devel