After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 770239 - SAVP doesn't seem to work when restreaming an RTSP source
SAVP doesn't seem to work when restreaming an RTSP source
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
Other Linux
: Normal blocker
: 1.10.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2016-08-22 15:55 UTC by Jay Kominek
Modified: 2016-11-23 12:10 UTC
See Also:
GNOME target: ---
GNOME version: ---

3 programs which, combined, demonstrate the issue (1.38 KB, application/zip)
2016-08-22 15:55 UTC, Jay Kominek
stream: block the output pads of rtpbin instead of the source bin (2.64 KB, patch)
2016-11-21 12:42 UTC, Matthew Waters (ystreet00)
accepted-commit_now Details | Review

Description Jay Kominek 2016-08-22 15:55:51 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 (, 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.
Comment 1 Hyunjun Ko 2016-08-23 03:32:42 UTC
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.
Comment 2 Matthew Waters (ystreet00) 2016-11-21 12:42:09 UTC
Created attachment 340417 [details] [review]
stream: block the output pads of rtpbin instead of the source bin
Comment 3 Sebastian Dröge (slomo) 2016-11-21 15:55:48 UTC
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.
Comment 4 Matthew Waters (ystreet00) 2016-11-23 12:10:11 UTC
commit b38eb8e99efe0147b15ed443d2481d3786d9e1df
Author: Matthew Waters <>
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.

1.10 5011f59b421922aae6fbfce680f0edc3ec13c6b1