[gst-devel] RTP Caps,base payloader and jrtplib

[Thomas Vander Stichele]

On Wed, 2005-11-02 at 12:41 -0500, burgerman at users.sourceforge.net
wrote:
> On Wed, 2 Nov 2005 18:09:20 +0200 (EET)
> Kai Vehmanen <kvehmanen at eca.cx> wrote:
> 
> > Hi,
> > 
> > On Wed, 2 Nov 2005, Thomas Vander Stichele wrote:
> > 
> > >> Do you really need these values (ssrc, timestamp, sequence), in session
> > >> descriptions? These are by nature random, and should be handled within the
> > >> RTP stack.
> > > Take for example an RTSP server.  The transport header in the RTSP reply
> > > to a SETUP command should list the ssrc that is going to be used for
> > > this RTP stream.  The RTP-Info header in the RTSP reply to a PLAY
> > > command should list seq and rtptime at which the stream for that client
> > > starts.  The RTP spec suggests that rtptime and seqnum start at a
> > > randomized value.
> > 
> > hmm, you're right. So the RTSP server needs a way to query the start 
> > values for ts+seqno, and current ssrc. I'll leave it to burger to 
> > comment how this fits with rtpbin... ;)
> 
> Currently the SSRC/ts start and seg start are generated randomly by the
> payloader AND rtpbin. They are not generated by the RTSP element.

We're not using rtpbin.  What RTSP element ? I'm not using a GStreamer
RTSP element.

> Therefore they are only generated after the stream is started or
> elements created. So I don't see how this can help RTSP unless there is
> a way to query these values from the payloader.

I don't understand what you're saying.  It's very simple.  The server
starts up a stream.  filesrc ! demux ! rtpenc ! multiudpsink is a sample
pipeline in that case.

Now, for every client that does an RTSP SETUP request (which will cause
this client to be added to multiudpsink), as I said before, the ssrc
needs to be returned.  This is the ssrc value that the rtpencoder chose
randomly.  a PLAY request should return, among other things, the rtptime
and seqnum at the point where that client is being added.

What is not clear about this ?


>  So in any case why have
> them inside the caps ? I am not saying these values will not be
> available or will not be random, I am just saying they don't need to be
> in the caps and they don't need and to be generated in the payloader,
> since it is all already done in rtpbin. 

Again: there are valid use cases for using payloaders without rtpbin.
If the ssrc is generated in the payloader, you should be able to get it
from the payloader.  if the payloader is picking a starting seqnum and
rtptime, an app should be able to ask the payloader what it picked.

If rtpbin somehow duplicates this functionality, it should do so by
asking these payloaders.  Not implement it on its own.

> Does the stream go through the RTSP server BEFORE it sends the SETUP
> reply and the PLAY commands so it can get the values from the CAPS ? 

What does that mean, "a stream going through the RTSP server" ?

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
- I didn't say I wanted you out of my life.
It's just...with the ironing, the new mattress,
they all just seem like things that are a little further
down the line, that's all.
- Further down the line than all the sex we've been having?
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/