GNOME Bugzilla – Bug 648520
Improvement idea: make rtsp extensions more flexible
Last modified: 2014-11-28 21:06:09 UTC
Trying to implement a Real Media specific way to set the bandwidth for a session (see attachments), I found the (to me) unsolvable problem to propagate the "bandwidth" parameter from a gstrtpsession to a specific extension. At my ignorant eyes, it looks like rtsp extensions live by their own, not being aware neither of the pipeline they're working into nor of the rtspsrc element they're bound to. As a solution, I would propose to add a method to notify the extensions with at least a pointer to the latter. Moreover, I found that as long as the rtspreal plugin is installed, any rtsp client based on GStreamer will expose itself as a RealMedia player.. pretty reductive, but it can probably be fixed with a fix in rtsp_ext_real_before_send to parse the URI and determine whether the stream has some probabilities to be powered by a real server before connecting to it. As it would be just an heuristic and very likely to fail in many cases, it would alternatively be good to allow gstrtspsrc to "probe" the server with a suitable method (OPTIONS?) and leave the extensions to process the OK response before altering what a client declares to be. In the case of rtspreal, it would probably require to send the OPTIONS twice, but imo it shouldn't require a modification in the design of the rtsp extensions.
Created attachment 186524 [details] [review] second part of the proof-of-concept patches
I don't think this is the patch you meant to attach.
(In reply to comment #2) > I don't think this is the patch you meant to attach. Actually, it wants to show that there's no way for an RTSP extension to get the bitrate property from an rtspsrc. I was working on a proper fix, but I stumbled in several regressions (or at least they appear to be so) with the new asynchronous implementation of rtspsrc. For instance, connecting with the URI from playbin2 works, but not using a simple rtspsrc ! fakesink pipeline. If you wan I can file a separate bug on the issue.
(In reply to comment #2) > I don't think this is the patch you meant to attach. to be more clear, actually the first part is missing.. btw, trying to rebase it on master HEAD I found several regressions with the new rtsp asynchronous implementation. E.g. the connection with the server succesfully occurs when using playbin2, but is very racy (for instance, works when stepping with GDB but not otherwise) when using rtspsrc ! fakesink. Do you want me to file a new bug?
Yes, please new bug for the regressions.
what's up with this?