1. 17 Jul, 2019 1 commit
  2. 28 Jun, 2019 1 commit
    • Göran Jönsson's avatar
      rtsp-stream: Not wait on receiver streams when pre-rolling · d1d40491
      Göran Jönsson authored
      Without this patch there are problem pre-rolling when using audio back
      channel.
      
      Without this patch a probe will be created for all streams including
      the stream for audio backchannel. To pre-roll all this pads have to
      receive data. Since the stream for audio backchannel is a receiver this
      will never happen.
      
      The solution is to never create any probes for streams that are for
      incomming data and instead set them as blocking already from beginning.
      d1d40491
  3. 25 Jun, 2019 1 commit
  4. 12 Jun, 2019 1 commit
    • Mathieu Duponchelle's avatar
      rtsp-media: make sure streams are blocked when sending seek · ab372863
      Mathieu Duponchelle authored
      The recent ONVIF work exposed a race condition when dealing with
      multiple streams: one of the sinks may preroll before other streams
      have started flushing. This led to the pipeline posting async-done
      prematurely, when some streams were actually still in the middle
      of performing a flushing seek. The newly-added code looks up a
      sticky segment event on the first stream in order to respond to
      the PLAY request with accurate Scale and Speed headers. In the
      failure condition, the first stream was flushing, and thus had
      no sticky segment event, leading to the PLAY request failing,
      and in turn the test.
      ab372863
  5. 07 Jun, 2019 1 commit
  6. 06 Jun, 2019 2 commits
  7. 04 Jun, 2019 6 commits
  8. 02 Jun, 2019 1 commit
    • Niels De Graef's avatar
      meson: Bump minimal GLib version to 2.44 · e788fc4e
      Niels De Graef authored
      This means we can use some newer features and get rid of some
      boilerplate code using the G_DECLARE_* macros.
      
      As discussed on IRC, 2.44 is old enough by now to start depending on it.
      e788fc4e
  9. 31 May, 2019 1 commit
  10. 29 May, 2019 1 commit
  11. 16 May, 2019 1 commit
  12. 14 May, 2019 1 commit
  13. 13 May, 2019 2 commits
  14. 23 Apr, 2019 3 commits
  15. 22 Apr, 2019 3 commits
  16. 19 Apr, 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.
      3cfe8863
  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.
      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
  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)
      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
  25. 04 Mar, 2019 1 commit
  26. 26 Feb, 2019 1 commit
  27. 19 Feb, 2019 1 commit