1. 29 Jun, 2017 1 commit
  2. 22 Jun, 2017 1 commit
  3. 16 Jun, 2017 1 commit
  4. 15 Jun, 2017 1 commit
    • Sebastian Dröge's avatar
      rtspsrc: Use a mutex for protecting against concurrent send/receives · a722f6e8
      Sebastian Dröge authored
      We currently send data to the RTSP connection from multiple threads:
      whenever a command is to be handled and whenever RTCP is generated. This
      can cause data corruption or worse if both happen at the same time.
      
      As such, protect gst_rtsp_connection_send() and gst_rtsp_connection_receive()
      calls with a mutex. While this means that we hold a mutex during the IO
      operation, this is not actually a problem as the IO operation can be
      interrupted (gst_rtsp_connection_flush()) at any time and is blocking by
      itself anyway.
      a722f6e8
  5. 07 Jun, 2017 1 commit
  6. 16 May, 2017 1 commit
  7. 21 Apr, 2017 1 commit
    • Sebastian Dröge's avatar
      rtspsrc: Chain up to the parent class' provide_clock() implementation · c99f7579
      Sebastian Dröge authored
      If no clock was provided directly by rtspsrc. This behaviour was removed
      by f8013487 and results in rtspsrc not
      providing the system clock via the rtpjitterbuffer.
      
      As a result, if another element like an audio sink, provides a clock,
      the pipeline would select that (when going to PAUSED/PLAYING again later).
      Audio clocks usually don't progress in PAUSED, and thus our live source
      won't be able to use the clock to produce data, making the sink never
      preroll and everything is stuck.
      c99f7579
  8. 17 Apr, 2017 1 commit
  9. 13 Feb, 2017 1 commit
  10. 26 Jan, 2017 1 commit
  11. 09 Jan, 2017 1 commit
  12. 05 Dec, 2016 2 commits
  13. 21 Nov, 2016 1 commit
  14. 01 Nov, 2016 2 commits
  15. 26 Oct, 2016 1 commit
    • Mark Nauwelaerts's avatar
      rtspsrc: reset connection info to non-flushing when closing · 73592423
      Mark Nauwelaerts authored
      This solves a hanging mainloop in following scenario:
      * connect to source
      * network/server drops
      * pipeline set to NULL (and connection to flushing as part)
      * pipeline set to PAUSED/PLAYING (connection to non-flushing, but not recorded)
      * [connecting still not possible]
      * pipeline set to NULL => mainloop hangs (since no actual flushing is done)
      73592423
  16. 15 Sep, 2016 1 commit
  17. 26 Aug, 2016 1 commit
  18. 20 Aug, 2016 1 commit
  19. 17 Aug, 2016 1 commit
  20. 06 Jul, 2016 1 commit
  21. 05 Jul, 2016 1 commit
  22. 01 Jul, 2016 1 commit
  23. 28 Jun, 2016 1 commit
    • Sebastian Dröge's avatar
      rtspsrc: When seeking, consider the current element state or pending state... · c18b609c
      Sebastian Dröge authored
      rtspsrc: When seeking, consider the current element state or pending state instead of the RTSP state
      
      If we consider the RTSP state, what can happen is that it is PLAYING but the
      element already asynchronously tried to PAUSE and it just did not happen yet.
      
      We would then override this setting to PAUSED (while the element actually is
      in PAUSED) and set the RTSP state to PLAYING again. This would then cause us
      to produce packets while the sinks are all PAUSED, piling up thousands of
      packets in the rtpjitterbuffer and other elements and finally failing.
      c18b609c
  24. 20 Jun, 2016 1 commit
  25. 17 May, 2016 1 commit
  26. 27 Apr, 2016 2 commits
  27. 15 Apr, 2016 1 commit
  28. 03 Apr, 2016 1 commit
  29. 24 Mar, 2016 2 commits
  30. 28 Feb, 2016 1 commit
  31. 18 Jan, 2016 1 commit
  32. 31 Dec, 2015 1 commit
  33. 14 Dec, 2015 2 commits
  34. 15 Nov, 2015 1 commit
  35. 25 Sep, 2015 1 commit