[gst-devel] The Future of RTP

Zeeshan Ali zeenix at gmail.com
Sun Apr 3 13:56:09 CEST 2005

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.

> 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.

> iii) Provide hooks to the app allowing app to monitor and use rtcp port

   Hey! Now you are stealing my ideas :)

More information about the gstreamer-devel mailing list