[gstreamer-bugs] [Bug 632207] rtspsrc GET_PARAMETER SET_PARAMETER

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=632207
  GStreamer | gst-plugins-good | 0.10.25

--- Comment #2 from Levente Farkas <lfarkas at lfarkas.org> 2010-10-15 11:43:41 UTC ---
(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:-)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.