[Bug 719635] rtspsrc: provide 'control' attribute from SDP in new pad caps

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Tue Jan 7 05:23:52 PST 2014


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

--- Comment #6 from Andrey Utkin <me at andrey-utkin.pp.ua> 2014-01-07 13:23:47 UTC ---
(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

-- 
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.


More information about the gstreamer-bugs mailing list