GNOME Bugzilla – Bug 770239
SAVP doesn't seem to work when restreaming an RTSP source
Last modified: 2016-11-23 12:10:11 UTC
Created attachment 333922 [details] 3 programs which, combined, demonstrate the issue We've got a program which takes in a number of RTSP streams, munges them, and re-serves them via RTSP, optionally with SAVP turned on. As of commit 85c52e194bcb81928b96614be0ae47d59eccb1ce (https://github.com/GStreamer/gst-rtsp-server/commit/85c52e194bcb81928b96614be0ae47d59eccb1ce), the last RTSP server in the "chain" seems to have problems setting up the crypto stuff when SAVP is turned on, and never manages to send anything to the client. 0:00:01.898853687 18188 0x159d1e0 ERROR default rtsp-sdp.c:441:make_media: unable to add MIKEY crypto sessions for stream 0 0:00:01.898872897 18188 0x159d1e0 ERROR default rtsp-sdp.c:481:gst_rtsp_sdp_from_media: could not get SDP from stream 0x7f5cd40365f0 0:00:01.898878155 18188 0x159d1e0 ERROR default rtsp-sdp.c:520:gst_rtsp_sdp_from_media: could not get SDP from media 0x7f5cd4031180 0:00:01.898882053 18188 0x159d1e0 ERROR rtspclient rtsp-client.c:2200:create_sdp: client 0x15ab8c0: could not create SDP 0:00:01.898888032 18188 0x159d1e0 ERROR rtspclient rtsp-client.c:2321:handle_describe_request: client 0x15ab8c0: can't create SDP Turning off SAVP, or using gst-rtsp-server from before that commit both work. I've attached three stripped down programs to demonstrate the problem. A & C are trivial, and just provided for your testing convenience. example-a is a trivial RTSP server of h264 encoded video example-c is a trivial gst-launch client of h264 encoded video example-b is the interesting bit. It connects to example-a, and then restreams it with SAVP enabled, for example-c's consumption. The a->b streaming appears to work fine, but b->c fails, as described above. Let me know if I can provide any more information or explanation of the issue.
I can reproduce this issue more easily. If rtsp-server serves a live pipeline (eg. videotestsrc is-live=true), this issue happens. Because, it should be working with no preroll, which means no chain function (of rtpbin in rtsp-server) is performed in the stage of creating sdp. Even if I hacks to make rtp source as a sender, it still happens. The problem is that it seems to be able to get rollover count once after srtp encoder starts.
Created attachment 340417 [details] [review] stream: block the output pads of rtpbin instead of the source bin
Review of attachment 340417 [details] [review]: ::: gst/rtsp-server/rtsp-stream.c @@ +3698,3 @@ + for (i = 0; i < 2; i++) { + if (priv->blocked_id[i] == 0) { + priv->blocked_id[i] = gst_pad_add_probe (priv->send_src[i], You probably also want to check if the pad exists here. RTCP can be disabled.
commit b38eb8e99efe0147b15ed443d2481d3786d9e1df Author: Matthew Waters <matthew@centricular.com> Date: Mon Nov 21 23:29:56 2016 +1100 stream: block the output of rtpbin instead of the source pipeline 85c52e194bcb81928b96614be0ae47d59eccb1ce introduced a more correct detection of the srtp rollover counter to add to the SDP. Unfortunately, it was incomplete for live pipelines where the logic blocks the source bin before creating the SDP and thus would never have the necessary informaiton to create a correct SDP with srtp encryption. Move the pad blocks to rtpbin's output pads instead so that the necessary information can be created before we need the information for the SDP. https://bugzilla.gnome.org/show_bug.cgi?id=770239 1.10 5011f59b421922aae6fbfce680f0edc3ec13c6b1