1. 21 Oct, 2020 1 commit
  2. 20 Oct, 2020 2 commits
  3. 25 Sep, 2020 1 commit
    • Mathieu Duponchelle's avatar
      rtsp-stream: explicitly set caps on udpsrc elements · a74bbdf8
      Mathieu Duponchelle authored
      This causes them to send caps events before data flow, which is
      usually a pretty correct thing to do!
      Not doing so manifested in a bug where ssrcdemux wouldn't forward
      the caps it had received with an extra ssrc field, as it hadn't
      received any caps event.
      Fixes #85
      Part-of: <!153>
  4. 24 Sep, 2020 1 commit
  5. 21 Sep, 2020 1 commit
    • Sebastian Dröge's avatar
      rtspclientsink: Set async-handling=false for the internal bins · ed189750
      Sebastian Dröge authored
      Without this we can easily run into a race condition with async state changes:
      - the pipeline is doing an async state change
      - we set the internal bins to PLAYING but that's ignored because an
        async state change is currently pending
      - the async state change finishes but does not change the state of the
        internal bins because of locked_state==TRUE
      - the internal bins stay in PAUSED forever
      Part-of: <!151>
  6. 06 Jun, 2020 1 commit
    • Sebastian Dröge's avatar
      rtsp-auth: Fix NULL pointer dereference when handling an invalid basic Authorization header · ccc8d0c4
      Sebastian Dröge authored
      When using the basic authentication scheme, we wouldn't validate that
      the authorization field of the credentials is not NULL and pass it on
      to g_hash_table_lookup(). g_str_hash() however is not NULL-safe and will
      dereference the NULL pointer and crash.
      A specially crafted (read: invalid) RTSP header can cause this to
      As a solution, check for the authorization to be not NULL before
      continuing processing it and if it is simply fail authentication.
      This fixes CVE-2020-6095 and TALOS-2020-1018.
      Discovered by Peter Wang of Cisco ASIG.
  7. 04 Feb, 2020 1 commit
  8. 13 Dec, 2019 1 commit
  9. 03 Dec, 2019 1 commit
  10. 12 Nov, 2019 1 commit
  11. 11 Nov, 2019 1 commit
    • Kristofer's avatar
      rtsp-client: RTP Info when completed_sender · 4bad948e
      Kristofer authored
      Change condition that should be fulfilled regarding RTPInfo.
      Replace !gst_rtsp_media_is_receive_only with
      gst_rtsp_media_has_completed_sender. It is more correct to actually look
      for a sender pipeline that is complete. Only then a RTPInfo should
      gst_rtsp_media_is_receive_only gives different answears depending on
      state of server.
      If Describe is called wth URL+options for backchannel SDP will give only
      audio and only backchannel a=sendonly
      If Describe is called on URL+options that gives both audio and video
      direction from server to client, pipelines are created. Thus
      receive_only will return false, even though Setup only would setup
      RTP-Info is only for outgoing streams. Thus one should look if outgoing
      streams are complete.
  12. 17 Oct, 2019 1 commit
  13. 23 Sep, 2019 1 commit
  14. 08 Sep, 2019 1 commit
  15. 06 Aug, 2019 4 commits
  16. 02 May, 2019 1 commit
  17. 18 Apr, 2019 1 commit
  18. 15 Apr, 2019 1 commit
  19. 11 Apr, 2019 1 commit
    • Göran Jönsson's avatar
      rtsp_server: Free thread pool before clean transport cache · 3cfe8863
      Göran Jönsson authored
      If not waiting for free thread pool before clean transport caches, there
      can be a crash if a thread is executing in transport list loop in
      function send_tcp_message.
      Also add a check if priv->send_pool in on_message_sent to avoid that a
      new thread is pushed during wait of free thread pool. This is possible
      since when waiting for free thread pool mutex have to be unlocked.
  20. 10 Apr, 2019 2 commits
  21. 27 Mar, 2019 1 commit
  22. 23 Mar, 2019 2 commits
    • Tim-Philipp Müller's avatar
      g-i: pass --quiet to g-ir-scanner · 0becf0b6
      Tim-Philipp Müller authored
      This suppresses the annoying 'g-ir-scanner: link: cc ..' output
      that we get even if everything works just fine.
      We still get g-ir-scanner warnings and compiler warnings if
      we pass this option.
    • Tim-Philipp Müller's avatar
      g-i: silence 'nested extern' compiler warnings when building scanner binary · 6f434615
      Tim-Philipp Müller authored
      We need a nested extern in our init section for the scanner binary
      so we can call gst_init to make sure GStreamer types are initialised
      (they are not all lazy init via get_type functions, but some are in
      exported variables). There doesn't seem to be any other mechanism to
      achieve this, so just remove that warning, it's not important at all.
  23. 21 Mar, 2019 1 commit
  24. 20 Mar, 2019 1 commit
    • Göran Jönsson's avatar
      rtsp-media: Handle set state when preparing. · 1fd49d36
      Göran Jönsson authored
      Handle the situation when  a call to gst_rtsp_media_set_state is done
      when media status is preparing.
      Also add unit test for this scenario.
      The unit test simulate on a media level when two clients share a (live)
      Both clients have done SETUP and got responses. Now client 1 is doing
      play and client 2 is just closing the connection.
      Then without patch there are a problem when
      client1 is calling gst_rtsp_media_unsuspend in handle_play_request.
      And client2 is doing closing connection we can end up in a call
      to gst_rtsp_media_set_state when
      priv->status == GST_RTSP_MEDIA_STATUS_PREPARING and all the logic for
      shut down media is jumped over .
      With this patch and this scenario we wait until
      priv->status == GST_RTSP_MEDIA_STATUS_PREPARED and then continue to
      execute after that and now we will execute the logic for
      shut down media.
  25. 04 Mar, 2019 1 commit
  26. 26 Feb, 2019 1 commit
  27. 19 Feb, 2019 1 commit
  28. 02 Feb, 2019 1 commit
  29. 30 Jan, 2019 3 commits
  30. 29 Jan, 2019 2 commits
  31. 25 Jan, 2019 1 commit
    • Lars Wireen's avatar
      rtsp-media: Fix race codition in finish_unprepare · ae32203c
      Lars Wireen authored
      The previous fix for race condition around finish_unprepare where the
      function could be called twice assumed that the status wouldn't change
      during execution of the function. This assumption is incorrect as the
      state may change, for example if an error message arrives from the
      pipeline bus.
      Instead a flag keeping track on whether the finish_unprepare function
      is currently executing is introduced and checked.
      Fixes #59