1. 21 Dec, 2018 1 commit
  2. 16 Aug, 2018 1 commit
  3. 26 Jul, 2018 1 commit
  4. 06 Jun, 2018 1 commit
  5. 23 May, 2018 1 commit
  6. 06 May, 2018 1 commit
  7. 25 Apr, 2018 1 commit
  8. 17 Apr, 2018 1 commit
  9. 26 Mar, 2018 1 commit
  10. 01 Mar, 2018 1 commit
  11. 16 Feb, 2018 3 commits
  12. 22 Jan, 2018 1 commit
    • Sebastian Dröge's avatar
      rtspsrc: Fix up sendonly/recvonly attribute handling · af273b4d
      Sebastian Dröge authored
      We can't handle recvonly streams, sendonly streams are perfectly fine.
      
      The direction is the one from the point of view of the SDP offerer
      (i.e. the RTSP server), and a recvonly stream would be one where the
      server expects us to send media.
      
      RFC 3264, section 5.1:
         If the offerer wishes to only send media on a stream to its peer, it
         MUST mark the stream as sendonly with the "a=sendonly" attribute.
      
      This is mixed up in the ONVIF streaming specification examples, but
      actual implementations and conformance tools seem to not care at all
      about the attributes.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=792376
      af273b4d
  13. 23 Dec, 2017 1 commit
  14. 19 Dec, 2017 1 commit
    • Edward Hervey's avatar
      rtspsrc: Fix two leaks · 9a7dd45e
      Edward Hervey authored
      * gst_event_new_stream_start() does not take ownership of the stream_id
      
      * the pipeline_request_id string that is created was not being freed
      9a7dd45e
  15. 06 Dec, 2017 1 commit
  16. 24 Nov, 2017 1 commit
    • Edward Hervey's avatar
      rtspsrc: Do more checks for seekability · 10bc8fdf
      Edward Hervey authored
      When receiving a seek event, check whether we can actually seek based
      on the information the server provided.
      
      Also add more documentation on what the seekable field means
      10bc8fdf
  17. 21 Nov, 2017 1 commit
  18. 01 Nov, 2017 2 commits
  19. 16 Oct, 2017 1 commit
  20. 09 Oct, 2017 1 commit
  21. 07 Oct, 2017 1 commit
  22. 05 Oct, 2017 4 commits
  23. 01 Oct, 2017 1 commit
  24. 15 Sep, 2017 1 commit
    • Patrick Radizi's avatar
      rtpbin: add option for sanity checking timestamp offset · 3de02445
      Patrick Radizi authored
      Timestamp offsets needs to be checked to detect unrealistic values
      caused for example by NTP clocks not in sync. The new parameter
      max-ts-offset lets the user decide an upper offset limit. There
      are two different cases for checking the offset based on if
      ntp-sync is used or not:
      1) ntp-sync enabled
         Only negative offsest are allowed since a positive offset would
         mean that the sender and receiver clocks are not in sync.
         Default vaule of max-ts-offset = 0 (disabled)
      2) ntp-sync disabled
         Both positive and negative offsets are allowed.
         Default vaule of max-ts-offset = 3000000000
      The reason for different default values is to be backwards
      compatible.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=785733
      3de02445
  25. 14 Sep, 2017 1 commit
  26. 29 Jun, 2017 1 commit
  27. 22 Jun, 2017 1 commit
  28. 16 Jun, 2017 1 commit
  29. 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
  30. 07 Jun, 2017 1 commit
  31. 16 May, 2017 1 commit
  32. 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
  33. 17 Apr, 2017 1 commit
  34. 13 Feb, 2017 1 commit