Skip to content
Snippets Groups Projects
  1. May 05, 2020
  2. Feb 12, 2020
    • Sebastian Dröge's avatar
      sctp: Take some socket configurations from Firefox's datachannel code · 26a6b175
      Sebastian Dröge authored and Sebastian Dröge's avatar Sebastian Dröge committed
      - Do not send ABORTs for unexpected packets are as response to INIT
      - Enable interleaving of messages of different streams
      - Configure 1MB send and receive buffer for the socket
      - Enable SCTP_SEND_FAILED_EVENT and SCTP_PARTIAL_DELIVERY_EVENT events
      - Set SCTP_REUSE_PORT configuration
      - Set SCTP_EXPLICIT_EOR and the corresponding send flag. We probably
        want to split packets to a maximum size later and only set the flag
        on the last packet. Firefox uses 0x4000 as maximum size here.
      - Enable SCTP_ENABLE_CHANGE_ASSOC_REQ
      - Disable PMTUD and set an maximum initial MTU of 1200
      26a6b175
    • Sebastian Dröge's avatar
      sctp: Start connection synchronously when starting the association · c4973702
      Sebastian Dröge authored and Sebastian Dröge's avatar Sebastian Dröge committed
      Calling bind() only sets up some data structures and calling connect()
      only produces one packet before it returns. That packet is stored in a
      queue that is asynchronously forwarded by the encoder's source pad loop,
      so not much is happening there either. Especially no waiting is
      happening here and no forwarding of data to other elements.
      
      This fixes a race condition during connection setup: the connection
      would immediately fail if we pass a packet from the peer to the socket
      before bind() and connect() have returned.
      
      This can't happen anymore as bind() and connect() have returned already
      before both elements reach the PAUSED state, and in webrtcbin there is
      an additional blocking pad probe before the decoder that does not let
      any data pass through before that anyway.
      c4973702
    • Sebastian Dröge's avatar
      sctp: Switch back to a non-recursive mutex and don't hold it while calling any usrsctp functions · 4c5c6e68
      Sebastian Dröge authored and Sebastian Dröge's avatar Sebastian Dröge committed
      The library is thread-safe by itself and potentially calls back into our
      code, not only from the same thread but also from other threads. This
      can easily lead to deadlocks if we try to hold our mutex on both sides.
      4c5c6e68
  3. Jan 31, 2020
  4. Jan 30, 2020
  5. Nov 06, 2019
    • Niels De Graef's avatar
      Don't pass default GLib marshallers for signals · d8f61515
      Niels De Graef authored and GStreamer Marge Bot's avatar GStreamer Marge Bot committed
      By passing NULL to `g_signal_new` instead of a marshaller, GLib will
      actually internally optimize the signal (if the marshaller is available
      in GLib itself) by also setting the valist marshaller. This makes the
      signal emission a bit more performant than the regular marshalling,
      which still needs to box into `GValue` and call libffi in case of a
      generic marshaller.
      
      Note that for custom marshallers, one would use
      `g_signal_set_va_marshaller()` with the valist marshaller instead.
      d8f61515
  6. Aug 20, 2019
    • Nirbheek Chauhan's avatar
      sctp: Fix crash on free() when using the MSVC binaries · 70a90f0e
      Nirbheek Chauhan authored
      On Windows, if libusrsctp and gstreamer are built with different
      C runtimes (CRT), we cannot free memory allocated inside libusrsctp
      with the `free()` function from gstreamer's CRT.
      
      `usrsctp_freedumpbuffer()` simply calls `free()`, but because of the
      way DLLs work on Windows, it will always call the free function from
      the correct CRT.
      70a90f0e
  7. Apr 26, 2019
  8. Sep 21, 2018
Loading