[gst-devel] The Future of RTP

[Zaheer Abbas Merali]

On Mon, 2005-04-04 at 01:55 +0500, Zeeshan Ali wrote:
> Hello Zaheer,
> 
> > RTCP is essential and that is why just udpsink as currently implemented
> > is not good enough.
> 
>   Please be reminded that it's not just udpsink we should be able to
> work with but tcp*sink and any transport elements we may have. Would
> it be possible to write an RTP sink that handles all possibilities?
> 
> >  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
> 
>    Thinking about this, i got struck by another idea: Why not have
> another pad for RTCP inside the packet encoding elements, so that the
> app. connects it with two udpsink elements, instead of one? Simillarly
> we can have the packet parsers to be connected with two udpsrc's.
> 

How about using GstEvents encapsulating rtcp messages, as a) rtcp is not
a continuous media stream and b) rtcp messages are usually congestion
control events or traffic statistics messages.

> > ii) Based on buffer timestamp (and maybe other conditions), delay
> > sending packets to appropriate time
> 
>    Well the packet encoders can tell the peer sink element to wait for
> any amount of time using the timestamps on the buffers it pushes
> towards it.
> 

well theres already a timestamp on the buffer, the rtp sink should use
this and cached info of when the last packet was sent as well as
congestion info deduced from rtcp to decide when to send the new packet.

> > iii) Provide hooks to the app allowing app to monitor and use rtcp port
> 
>    Hey! Now you are stealing my ideas :)
-- 
Zaheer Abbas Merali <zaheerabbas at merali.org>