GNOME Bugzilla – Bug 719635
rtspsrc: provide 'control' attribute from SDP in new pad caps
Last modified: 2014-01-07 13:23:47 UTC
Patch changes original intended behaviour. But this attribute is useful for identifying the elementary stream. ---8<--- Appears as 'a-control' key in caps structure. --- gst/rtsp/gstrtspsrc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/gst/rtsp/gstrtspsrc.c b/gst/rtsp/gstrtspsrc.c index d363f2b..29f077f 100644 --- a/gst/rtsp/gstrtspsrc.c +++ b/gst/rtsp/gstrtspsrc.c @@ -1597,8 +1597,6 @@ gst_rtspsrc_sdp_attributes_to_caps (GArray * attributes, GstCaps * caps) continue; if (!strcmp (key, "rtpmap")) continue; - if (!strcmp (key, "control")) - continue; if (!strcmp (key, "range")) continue; -- 1.8.1.5
Created attachment 263231 [details] [review] patch
Up. Any interest?
Up.
Wim, what do you think? Does this make sense?
(In reply to comment #4) > Wim, what do you think? Does this make sense? I don't think we want to start adding those fields of the SDP on the caps, we only want to add those fields that describe the media type of the buffer. If anything, those extra things should be on pad properties or so. As an alternative I would suggest to use the on-sdp signal and the pt of the stream to derive the control url.
(In reply to comment #5) > I don't think we want to start adding those fields of the SDP on the caps, we > only want to add those fields that describe the media type of the buffer. If > anything, those extra things should be on pad properties or so. Readable property of pad would be useful, but it doesn't look like good idea to extend GstPad properties set for such case. I mean property would be unused in prevailing majority of cases. Passing this info in caps does not require extending fixed interfaces, which is better. > As an alternative I would suggest to use the on-sdp signal "To use on-sdp signal" is orthogonal to this. When you have caught on-sdp signal, you may still have to figure out which exactly stream it is, by matching with some parameter which _user_can_set_. > and the pt of the stream to derive the control url. Payload type number may not help. What about having two audio tracks, both of same audio encoding with staticically IANA-assigned payload type? You can see there's a lot of such: http://en.wikipedia.org/wiki/RTP_audio_video_profile#RTP.2FAVP_audio_and_video_payload_types