GNOME Bugzilla – Bug 703158
gst-rtsp-server: identify client of a stream transport
Last modified: 2013-10-04 04:47:29 UTC
I am using RTP session on-ssrc-active to adjust an encoder bitrate. I do that depending on fraction lost for the given on-ssrc-active source and other factors. From on-ssrc-active, there is no way to know which GstRTSPClient the source corresponds to.
Created attachment 247861 [details] [review] store client in stream transport With this, it is possible to retrieve the client associated with a stream transport. From on-ssrc-active, we get the RTP source which has a qdata (GstRTSPServer.stream) for the stream transport. And from that we get the client. However, GstRTSPServer.stream qdata is not documented anywhere. Not sure if it's supposed to be used.
It is not correct. A stream transport can have multiple (or no) clients.
(In reply to comment #2) > It is not correct. A stream transport can have multiple (or no) clients. I thought those were the streams. And that each stream had a list of stream transports, each one created by the setup request. GstRTSPStreamTransport only holds one GstRTSPTransport which seems only one client-server relationship. Obviously, I am missing something important.
> > Obviously, I am missing something important. The GstRTSPClient is just an object handling this particular client connection. What can happen is this: - client connects (gets GstRTSPClient object) - client does some things, opens session, starts RTP data transport - client closes connection (GstRTSPClient finilizes, RTP transport continues) - client connects again, new GstRTSPClient is created, uses session id to find previous session info, does some more things on its stream (PAUSE, PLAY etc) So, the Client object does not really model a Client but more like a connection with a client that comes and goes. This means that a stream can exist without a GstRTSPClient object. also, a stream can exist with multiple GstRTSPClient objects when the clients would use the same session id. It is possible for a client to open multiple connections and do operations on the session streams from both connections. Both of these situations are not very common but the data model allows them.
Thank you, that really helped. I was thinking everything as a one time connection where RTSP and RTP connections are always alive and related with single GstRTSPClient. Actually, this is how my use case works. I'll try to figure out a general case, if it makes sense at all.