1. 23 Sep, 2021 1 commit
  2. 05 Jul, 2021 1 commit
    • Göran Jönsson's avatar
      Protection against early RTCP packets. · 43572a89
      Göran Jönsson authored and GStreamer Marge Bot's avatar GStreamer Marge Bot committed
      When receiving RTCP packets early the funnel is not ready yet and
      GST_FLOW_FLUSHING will be returned when pushing data to it's srcpad.
      This causes the thread that handle RTCP packets to go to pause mode.
      Since this thread is in pause mode there will be no further callbacks to
      handle keep-alive for incoming RTCP packets. This will make the session
      time out if the client is not using another keep-alive mechanism.
      Change-Id: Idb29db05f59c06423fa693a2aeeacbe3a1883fc5
      Part-of: <!211>
  3. 21 Jun, 2021 1 commit
  4. 01 Jun, 2021 1 commit
  5. 31 May, 2021 1 commit
  6. 24 May, 2021 1 commit
  7. 05 May, 2021 3 commits
  8. 29 Apr, 2021 1 commit
  9. 27 Apr, 2021 2 commits
  10. 23 Apr, 2021 2 commits
  11. 20 Apr, 2021 1 commit
  12. 19 Mar, 2021 1 commit
  13. 15 Feb, 2021 4 commits
  14. 01 Feb, 2021 1 commit
    • Branko Subasic's avatar
      rtsp-stream: avoid deadlock in send_func · 6fc8b963
      Branko Subasic authored
      Currently the send_func() runs in a thread of its own which is started
      the first time we enter handle_new_sample(). It runs in an outer loop
      until priv->continue_sending is FALSE, which happens when a TEARDOWN
      request is received. We use a local variable, cont, which is initialized
      to TRUE, meaning that we will always enter the outer loop, and at the
      end of the outer loop we assign it the value of priv->continue_sending.
      Within the outer loop there is an inner loop, where we wait to be
      signaled when there is more data to send. The inner loop is exited when
      priv->send_cookie has changed value, which it does when more data is
      available or when a TEARDOWN has been received.
      But if we get a TEARDOWN before send_func() is entered we will get stuck
      in the inner loop because no one will increase priv->session_cookie
      By not entering the outer loop in send_func() if priv->continue_sending
      is FALSE we make sure that we do not get stuck in send_func()'s inner
      loop should we receive a TEARDOWN before the send thread has started.
      Change-Id: I7338a0ea60ea435bb685f875965f5165839afa20
      Part-of: <!187>
  15. 22 Jan, 2021 1 commit
    • Branko Subasic's avatar
      rtsp-client: cleanup transports during TEARDOWN · 2894640c
      Branko Subasic authored
      When tunneling RTP over RTSP the stream transports are stored in a hash
      table in the GstRTSPClientPrivate struct. They are used for, among other
      things, mapping channel id to stream transports when receiving data from
      the client. The stream tranports are created and added to the hash table
      in handle_setup_request(), but unfortuately they are not removed in
      handle_teardown_request(). This means that if the client sends data on
      the RTSP connection after it has sent the TEARDOWN, which is often the
      case when audio backchannel is enabled, handle_data() will still be able
      to map the channel to a session transport and pass the data along to it.
      Which eventually leads to a failing assert in gst_rtsp_stream_recv_rtp()
      because the stream is no longer joined to a bin.
      We avoid this by removing the stream transports from the hash table when
      we handle the TEARDOWN request.
      Part-of: <!184>
  16. 08 Jan, 2021 1 commit
  17. 23 Dec, 2020 2 commits
    • John Lindgren's avatar
      Add test cases for mountpoint of '/' · d6d3ecaa
      John Lindgren authored and John Lindgren's avatar John Lindgren committed
      Part-of: <!168>
    • John Lindgren's avatar
      Make a mount point of "/" work correctly. · c4762da9
      John Lindgren authored and John Lindgren's avatar John Lindgren committed
      As far as I can tell, this is neither explicitly allowed nor
      forbidden by RFC 7826.
      Meanwhile, URLs such as rtsp://<IP>:554 or rtsp://<IP>:554/ are in
      use in the wild (presumably with non-GStreamer servers).
      GStreamer's prior behavior was confusing, in that
      gst_rtsp_mount_points_add_factory() would appear to accept a mount
      path of "" or "/", but later connection attempts would fail with a
      "media not found" error.
      This commit makes a mount path of "/" work for either form of URL,
      while an empty mount path ("") is rejected and logs a warning.
      Part-of: <!168>
  18. 21 Dec, 2020 1 commit
  19. 17 Dec, 2020 1 commit
  20. 15 Dec, 2020 1 commit
  21. 14 Dec, 2020 1 commit
  22. 18 Nov, 2020 1 commit
  23. 16 Nov, 2020 1 commit
  24. 11 Nov, 2020 2 commits
  25. 23 Oct, 2020 1 commit
  26. 19 Oct, 2020 1 commit
  27. 10 Oct, 2020 1 commit
  28. 08 Oct, 2020 3 commits
  29. 30 Sep, 2020 1 commit