GNOME Bugzilla – Bug 632207
[rtspsrc] GET_PARAMETER / SET_PARAMETER support
Last modified: 2013-06-25 10:18:26 UTC
hi, currently gstreamer's rtspsrc support only: OPTIONS DESCRIBE SETUP PLAY TEARDOWN i don't know whether it's support PAUSE ANNOUNCE REDIRECT RECORD but sure it do not support GET_PARAMETER SET_PARAMETER this two last method would be very useful since in this case application developers can snd any kind of extra parameters during play to the server. eg: currently zoom into a video stream is not possible without rebuild the whole rtsp session or some kind of extra interface between the client and the server. imho this paramter get/set can be implemented via gstreamer properties easily. rstp spec: http://www.ietf.org/rfc/rfc2326.txt
(In reply to comment #0) > hi, > i don't know whether it's support > PAUSE It supports pause (when you pause the element) > ANNOUNCE > RECORD These are for instructing a server to start a recording, not relevant for a source element. > REDIRECT This is not supported yet > but sure it do not support > GET_PARAMETER > SET_PARAMETER rtspsrc will reply to a server sending these requests. It will also send a GET_PARAMETER (or OPTIONS) to a server in order to keep the session alive. It doesn't send anything interesting in those requests, though. > this two last method would be very useful since in this case application > developers can snd any kind of extra parameters during play to the server. eg: > currently zoom into a video stream is not possible without rebuild the whole > rtsp session or some kind of extra interface between the client and the server. > imho this paramter get/set can be implemented via gstreamer properties easily. > rstp spec: > http://www.ietf.org/rfc/rfc2326.txt It would indeed be interesting to do this. I was more thinking of making an action signal for the SET_PARAMETER and GET_PARAMETER. I'm guessing that the application would provide a string with the body of the [GS]ET_PARAMETER request and that the result of the signal would be a string with the body of the reply. Along with two regular signals for when the server sends a GET/SET_PARAMETER this would be a good addition.
(In reply to comment #1) > (In reply to comment #0) > It supports pause (when you pause the element) > > > ANNOUNCE > > RECORD > > These are for instructing a server to start a recording, not relevant for a > source element. but can be relevant to the user of the source element since otherwise can't send this command to the server through gstreamer, but should have to use some extermnal protocol (but it's not important for us right now:-) > > but sure it do not support > > GET_PARAMETER > > SET_PARAMETER > > rtspsrc will reply to a server sending these requests. i don't understand this sentence:-( > It will also send a GET_PARAMETER (or OPTIONS) to a server in order to keep the > session alive. It doesn't send anything interesting in those requests, though. > > > this two last method would be very useful since in this case application > > developers can snd any kind of extra parameters during play to the server. eg: > > currently zoom into a video stream is not possible without rebuild the whole > > rtsp session or some kind of extra interface between the client and the server. > > imho this paramter get/set can be implemented via gstreamer properties easily. > > rstp spec: > > http://www.ietf.org/rfc/rfc2326.txt > > It would indeed be interesting to do this. I was more thinking of making an > action signal for the SET_PARAMETER and GET_PARAMETER. I'm guessing that the > application would provide a string with the body of the [GS]ET_PARAMETER > request and that the result of the signal would be a string with the body of > the reply. > > Along with two regular signals for when the server sends a GET/SET_PARAMETER > this would be a good addition. yes may be this singal solution would be better. actually for me it's does not make a difference for me which solution, but it'd be useful to implement it. since with this addition all kind of client <-> server communication can be used in a generic environment. thanks:-)
(In reply to comment #2) > > > > but sure it do not support > > > GET_PARAMETER > > > SET_PARAMETER > > > > rtspsrc will reply to a server sending these requests. > > i don't understand this sentence:-( > RTSP servers send often send a GET/SET_PARAMETER request to a client to check if it is still alive. Some servers (like realmedia and windows) use these requests to query the status of the client and inform the client of the status of the server. What the sentence means is that rtspsrc will reply to a server that sends such a request. It always replies with 200 OK but doesn't really do anything else.
that's new to me! until now i assume only the client can initiate command to the server, but not the server to the client. does it means if i write the rtsp server and use gstreamer's rtspsrc as a client then i can "call" the client's from the server? in this case it'd be useful to add some signal to the rtspsrc: "get-parameter" "set-parameter" to be able to add user defined callback to these server requests. on the other hand it'd be useful to add the same kind of action signals to the rtspsrc too which then send these commands to the server. ps. anyway i'm not able to find any kind of documentation about the "Element Actions" signals. and i'm not able to understand why they called signals in the docs. what is the "Run Last" "Run First" in the docs. eg. in appsrc push-buffer should have to be called by the user. then why it's a signal? or what i misunderstood here? is there any docs about somewhere?
(In reply to comment #4) > that's new to me! until now i assume only the client can initiate command to > the server, but not the server to the client. > does it means if i write the rtsp server and use gstreamer's rtspsrc as a > client then i can "call" the client's from the server? Yes, I'm planning on doing that next.
commit 779bcc093cf9579106401cfd317b5e58908e3a28 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Thu Apr 25 15:25:06 2013 +0200 rtspsrc: add signal to handle server requests Add a signal to be notified of a server request. The signal handler can then construct the response message for the server. See https://bugzilla.gnome.org/show_bug.cgi?id=632207