Skip to content
Snippets Groups Projects
  1. May 30, 2019
  2. May 29, 2019
  3. May 06, 2019
  4. May 01, 2019
    • Edward Hervey's avatar
      rtsp-stream: Use cached address when allocating sockets · f11f127a
      Edward Hervey authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      If an address/port was previously decided upon (ex: multicast in the
      SDP), then use that instead of re-creating another one
      
      Fixes gstreamer/gst-rtsp-server#57
      f11f127a
    • Sebastian Dröge's avatar
      rtsp-server: Fix various Since markers · 64f67f0e
      Sebastian Dröge authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      64f67f0e
    • Sebastian Dröge's avatar
      rtsp-server: Add various Since: 1.14 markers · de92aecd
      Sebastian Dröge authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      de92aecd
    • Erlend Eriksen's avatar
      session pool: fix missing klass-> in klass->create_session · 5bef031d
      Erlend Eriksen authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      5bef031d
    • Göran Jönsson's avatar
      rtsp-media: Handle set state when preparing. · ac0be798
      Göran Jönsson authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      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.
      ac0be798
    • Benjamin Berg's avatar
      client: Fix crash in close handler · f39bdcae
      Benjamin Berg authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      The close handler could trigger a crash because it invalidated the
      watch_context while still leaving a source attached to it which would be
      cleaned up at a later point.
      f39bdcae
    • Lars Wireen's avatar
      rtsp-media: Fix race condition in finish_unprepare · cff88f07
      Lars Wireen authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      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 gstreamer/gst-rtsp-server#59
      cff88f07
    • Linus Svensson's avatar
      rtsp-stream: Use seqnum-offset for rtpinfo · 8c595bcf
      Linus Svensson authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      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
      8c595bcf
  5. Nov 10, 2018
  6. Oct 22, 2018
    • Edward Hervey's avatar
      rtsp-client: Remove timeout GSource on cleanup · 89f6f25e
      Edward Hervey authored and Edward Hervey's avatar Edward Hervey committed
      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).
      89f6f25e
  7. Oct 02, 2018
  8. Sep 16, 2018
  9. Aug 16, 2018
  10. Jul 20, 2018
  11. Jul 16, 2018
  12. Jul 12, 2018
  13. Jun 27, 2018
  14. Jun 21, 2018
  15. May 18, 2018
  16. May 17, 2018
  17. May 14, 2018
  18. Apr 20, 2018
  19. Apr 17, 2018
  20. Apr 16, 2018
  21. Mar 30, 2018
    • Mathieu Duponchelle's avatar
      rtspclientsink: Fix client ports for the RTCP backchannel · 3244a351
      Mathieu Duponchelle authored
      This was broken since the work for delayed transport creation
      was merged: the creation of the transports string depends on
      calling stream_get_server_port, which only starts returning
      something meaningful after a call to stream_allocate_udp_sockets
      has been made, this function expects a transport that we parse
      from the transport string ...
      
      Significant refactoring is in order, but does not look entirely
      trivial, for now we put a band aid on and create a second transport
      string after the stream has been completed, to pass it in
      the request headers instead of the previous, incomplete one.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=794789
      3244a351
  22. Mar 25, 2018
  23. Mar 19, 2018
  24. Mar 13, 2018
Loading