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

[burgerman at users.sourceforge.net]

On Thu, 03 Nov 2005 14:53:41 +0100
Thomas Vander Stichele <thomas at apestaart.org> wrote:

> 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.
Maybe you should start using it huh :)

> 
> > 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 ?
What is not clear is why are these values in the CAPS? why are they
needed to be in the caps? The client app can retreive them directly
from the payloader so why in the caps? 
What we have here is a simple case of duplicate functionality. Now you
are saying you don't use rtpbin, but the payloader base class has been
written a relatively short time ago, way after the rtpbin was written.
I think if you guys want to work with it you should do elements that
are in accord with it. I think this generation of the SSRC/ts start and
sq start should be in the rtpbin and have absolutly no reason to be
done either in the payloader or have them in the CAPS. someone tell me
otherwise and why.

> 
> 
> >  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/
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel