1. 16 May, 2019 1 commit
  2. 14 May, 2019 1 commit
  3. 13 May, 2019 2 commits
  4. 23 Apr, 2019 3 commits
  5. 22 Apr, 2019 3 commits
  6. 19 Apr, 2019 1 commit
  7. 18 Apr, 2019 1 commit
  8. 15 Apr, 2019 1 commit
  9. 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.
      3cfe8863
  10. 10 Apr, 2019 2 commits
  11. 27 Mar, 2019 1 commit
  12. 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.
      0becf0b6
    • 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.
      6f434615
  13. 21 Mar, 2019 1 commit
  14. 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)
      media.
      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.
      1fd49d36
  15. 04 Mar, 2019 1 commit
  16. 26 Feb, 2019 1 commit
  17. 19 Feb, 2019 1 commit
  18. 02 Feb, 2019 1 commit
  19. 30 Jan, 2019 3 commits
  20. 29 Jan, 2019 2 commits
  21. 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
      ae32203c
  22. 17 Jan, 2019 1 commit
  23. 06 Dec, 2018 1 commit
  24. 05 Dec, 2018 1 commit
  25. 20 Nov, 2018 2 commits
  26. 19 Nov, 2018 2 commits
  27. 17 Nov, 2018 1 commit
  28. 14 Nov, 2018 1 commit
    • Linus Svensson's avatar
      rtsp-stream: Use seqnum-offset for rtpinfo · 18538592
      Linus Svensson authored
      The sequence number in the rtpinfo is supposed to be the first RTP
      sequence number. The "seqnum" property on a payloader is supposed to be
      the number from the last processed RTP packet. The sequence number for
      payloaders that inherit gstrtpbasepayload will not be correct in case of
      buffer lists. In order to fix the seqnum property on the payloaders
      gst-rtsp-server must get the sequence number for rtpinfo elsewhere and
      "seqnum-offset" from the "stats" property contains the value of the
      very first RTP packet in a stream. The server will, however, try to look
      at the last simple in the sink element and only use properties on the
      payloader in case there no sink elements yet, and by looking at the last
      sample of the sink gives the server full control of which RTP packet it
      looks at. If the payloader does not have the "stats" property, "seqnum"
      is still used since "seqnum-offset" is only present in as part of
      "stats" and this is still an issue not solved with this patch.
      
      Needed for gst-plugins-base!17
      18538592