GNOME Bugzilla – Bug 720667
URI Query component not returned to clients in describe response
Last modified: 2014-06-28 11:25:00 UTC
Created attachment 264469 [details] patches rtspstream URI constructors A client could specify URI query entries which may carry value beyond just the describe stage. This should(?) be returned to clients, as clients may not add the query string back to the URL for the setup request. The attached diff hardcodes the behaviour to append this query string on all media entries that get returned to clients. This would probably have to be an optional behaviour, but does cover the base.
You should not dynamically create a control url that magically matches the request url. The idea is that the control url is placed in the SDP and that the client uses this url to access the stream later.
How I think this should go: 1) DESCRIBE /some/url/foo Makes a media and streams. You can configure the stream control url by setting the property on the stream when it is created. The the SDP is created that contains the control url for each stream. So suppose we have 3 audio streams for 3 languages, we could place this in the SDP: m=... a=control:audio?lang=nl m=... a=control:audio?lang=fr m=... a=control:audio?lang=de You would need to connect to the "new-stream" signal on the media and set the control url to these values. 2) Then a client will use SETUP /some/url/foo/audio?lang=XX for one of the languages and the stream with the right control url is retrieved. 3) a client can also do SETUP /some/url/foo/audio?lang=nl&bitrate=20000. In that case the audio?lang=nl stream is selected and bitrate=XXX is used as an extra parameters to configure the transport.
(In reply to comment #2) > 2) Then a client will use SETUP /some/url/foo/audio?lang=XX for one of the > languages and the stream with the right control url is retrieved. This happens automatically currently. The default make_path_from_uri will append the query parameters to construct the control url. > > 3) a client can also do SETUP /some/url/foo/audio?lang=nl&bitrate=20000. In > that case the audio?lang=nl stream is selected and bitrate=XXX is used as an > extra parameters to configure the transport. This you can implement by overriding the make_path_from_uri vmethod on the RTSPClient object. You will look at the uri and generate the path uri audio?lang=nl that uniquely identifies the stream. To use the other properties on the url to configure the stream, you would then override configure_client_transport in GstRTSPClient and use the context to configure the pipeline of the media. I would like to add a better method for this later.
Better way to configure the media and streams: commit 7a947e8dfe424664ffdfb5397d506f785397dcea Author: Wim Taymans <wtaymans@redhat.com> Date: Wed Dec 18 15:57:03 2013 +0100 client: add vmethod to configure media and streams Implement a vmethod that can be used to configure the media and the streams based on the current context. Handle the blocksize handling in the default handler. See https://bugzilla.gnome.org/show_bug.cgi?id=720667 Closing this now because I think the original problem can be handled with the current code.
This commit broke ABI if I'm not mistaken.. http://cgit.freedesktop.org/gstreamer/gst-rtsp-server/commit/?id=7a947e8dfe424664ffdfb5397d506f785397dcea
Nevermind, that was before the first stable 1.2.x release.