1. 01 Nov, 2018 5 commits
  2. 23 Oct, 2018 1 commit
  3. 22 Oct, 2018 1 commit
    • Edward Hervey's avatar
      rtsp-client: Remove timeout GSource on cleanup · ebafccb6
      Edward Hervey authored
      Avoids ending up with races where a timeout would still be around
      *after* a client was gone. This could happen rather easily in
      RTSP-over-HTTP mode on a local connection, where each RTSP message
      would be sent as a different HTTP connection with the same tunnelid.
      
      If not properly removed, that timeout would then try to free again
      a client (and its contents).
      ebafccb6
  4. 04 Oct, 2018 1 commit
  5. 03 Oct, 2018 1 commit
  6. 28 Sep, 2018 2 commits
  7. 24 Sep, 2018 1 commit
  8. 19 Sep, 2018 4 commits
  9. 01 Sep, 2018 1 commit
  10. 31 Aug, 2018 2 commits
  11. 29 Aug, 2018 2 commits
  12. 15 Aug, 2018 1 commit
  13. 14 Aug, 2018 16 commits
  14. 06 Aug, 2018 1 commit
  15. 01 Aug, 2018 1 commit
    • Mathieu Duponchelle's avatar
      rtsp-client: always allocate both IPV4 and IPV6 sockets · 12f8abb5
      Mathieu Duponchelle authored
      multiudpsink does not support setting the socket* properties
      after it has started, which meant that rtsp-server could no
      longer serve on both IPV4 and IPV6 sockets since the patches
      from https://bugzilla.gnome.org/show_bug.cgi?id=757488 were
      merged.
      
      When first connecting an IPV6 client then an IPV4 client,
      multiudpsink fell back to using the IPV6 socket.
      
      When first connecting an IPV4 client, then an IPV6 client,
      multiudpsink errored out, released the IPV4 socket, then
      crashed when trying to send a message on NULL nevertheless,
      that is however a separate issue.
      
      This could probably be fixed by handling the setting of
      sockets in multiudpsink after it has started, that will
      however be a much more significant effort.
      
      For now, this commit simply partially reverts the behaviour
      of rtsp-stream: it will continue to only create the udpsinks
      when needed, as was the case since the patches were merged,
      it will however when creating them, always allocate both
      sockets and set them on the sink before it starts, as was
      the case prior to the patches.
      
      Transport configuration will only error out if the allocation
      of UDP sockets fails for the actual client's family, this
      also downgrades the GST_ERRORs in alloc_ports_one_family
      to GST_WARNINGs, as failing to allocate is no longer
      necessarily fatal.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=796875
      12f8abb5