[gst-devel] The Future of RTP

[Zaheer Abbas Merali]

On Sun, 2005-04-03 at 23:46 +0500, Zeeshan Ali wrote:
> Hello everyone,
>     As you can all see that people are submitting patches for RTP
> stuff. But we are not in a position to do any justice with these
> patches until and unless the clouds of uncertainty over the future of
> RTP in the Gstreamer universe are cleared-off.
> 
>    The first issue is the separation of the RTP packet
> creation/encapsulation and parsing, and the actual transport of these
> packets. This separation is completely in accordance with the spirit
> of RTP but we don't have any clear vision of what will happen with the
> RTCP part, which is essential to RTP streaming. My idea was/is to
> leave the RTCP part to the the app. providing appropriate signals in
> the RTP packet parsing elements.
> 
>    Another rationale behind this separation is the fact that RTP
> packet encapsulation isn't so generic: i-e each media format has it's
> own way of being encapsulated. Based on this same reason and the
> licensing issues was also our decision to just copy the code we needed
> from an RTP library (1) which was just a modification of the code
> given in the RFCs instead of linking the plugin(s) with a 'generic'
> RTP library.
> 
>    This is the what i recall from our last discussion on the future
> directions of RTP development. But there has been worries and criticim
> popping-up regarding this plan. Anyway, we must now decide a 'clear'
> road map.
> 
> 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?
> 
>   On as side note, I was to work on librtsp and ramon was to work on
> the RTP. Unfortunately, I haven't made been able to make any
> significant progress on my part because of getting involved in other
> stuff after the economic failure of the video-whale project. Ramon
> seems to be working on and off but I do not know of anything
> committed/submitted by him. Maybe he got busy in other stuff too. :(
> Having said that, I might start to work full-time on RTP if i get this
> job I am quite hopeful about.
> 
> Regards,
> 
> Zeeshan Ali.
> 
> (1) I am unable to recall which lib. it was since we've been switching RTP libs.
> 

RTCP is essential and that is why just udpsink as currently implemented
is not good enough.  These are a few things an rtp sink should be able
to do for us:

i) Open both rtp and rtcp (usually rtp port + 1) ports
ii) Based on buffer timestamp (and maybe other conditions), delay
sending packets to appropriate time
iii) Provide hooks to the app allowing app to monitor and use rtcp port

I agree fully well that separate elements should encapsulate the codec
frames to relevant rtp packets, as each codec's rtp packetising rules
are different.

RTP sources, the same kind of argument applies

Whether using an existing rtp library or creating the code as part of
gst is irerelevant at this stages of discussion I believe.

Basically if we do RTP, we should do it properly and handle RTCP also.

I am sure the farsight guys will be able to give good feedback, as they
have actually used gstreamer with RTP interoperating with non gstreamer
RTP nodes.  Also would be nice if Wim detailed his proposed solution.

Remember this is completely separate from RTSP, which is just a
streaming protocol that initiate, negotiates and controls necessary
RTP/RTCP streams.


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