1. 16 Jun, 2019 1 commit
  2. 14 Jun, 2019 2 commits
  3. 13 Jun, 2019 2 commits
  4. 12 Jun, 2019 4 commits
    • Mikhail Fludkov's avatar
    • Stian Selnes's avatar
      rtpjitterbuffer: Fix delay for EXPECTED timers added by gaps · 6269ed49
      Stian Selnes authored
      This patch corrects the delay set on EXPECTED timers that are added when
      processing gaps. Previously the delay could be too small so that
      'timout + delay' was much less than 'now', causing the following retries
      to be scheduled too early. (They were sent earlier than
      rtx-retry-timeout after the previous timeout.)
    • Håvard Graff's avatar
      rtpjitterbuffer: don't try and calculate packet-rate if seqnum are jumping · 8ed7ab17
      Håvard Graff authored
      Turns out that the "big-gap"-logic of the jitterbuffer has been horribly
      For people using lost-events, an RTP-stream with a gap in sequencenumbers,
      would produce exactly that many lost-events immediately.
      So if your sequence-numbers jumped 20000, you would get 20000 lost-events
      in your pipeline...
      The test that looks after this logic "test_push_big_gap", basically
      incremented the DTS of the buffer equal to the gap that was introduced,
      so that in fact this would be more of a "large pause" test, than an
      actual gap/discontinuity in the sequencenumbers.
      Once the test was modified to not increment DTS (buffer arrival time) with
      a similar gap, all sorts of crazy started happening, including adding
      thousands of timers, and the logic that should have kicked in, the
      "handle_big_gap_buffer"-logic, was not called at all, why?
      Because the number max_dropout is calculated using the packet-rate, and
      the packet-rate logic would, in this particular test, report that
      the new packet rate was over 400000 packets per second!!!
      I believe the right fix is to don't try and update the packet-rate if
      there is any jumps in the sequence-numbers, and only do these calculations
      for nice, sequential streams.
    • Håvard Graff's avatar
      rtpjitterbuffer: fix unused variables · dd422f0b
      Håvard Graff authored
  5. 11 Jun, 2019 4 commits
  6. 06 Jun, 2019 2 commits
  7. 05 Jun, 2019 5 commits
  8. 04 Jun, 2019 3 commits
    • Nicolas Dufresne's avatar
      supp: Ignore leaks caused by shout/sethostent · f227f659
      Nicolas Dufresne authored
      sethostent() seems to be using a global state and we endup with leaks from
      that API when called through shout_init(). We had the option to only
      ignore the shout case, but the impression is that if we have shout and
      another sethostend user, as it's a global state, we may endup with a
      different stack trace for the same leak. So in the end, we just ignore
      memory allocated by sethostent in general.
    • Thibault Saunier's avatar
    • Nicolas Dufresne's avatar
      rtpssrcdemux: Avoid taking streamlock out-of-band · f7c712d0
      Nicolas Dufresne authored
      In this change we now protect the internal srcpads list using the
      stream lock and limit usage of the internal stream lock to
      preventing data flowing on the other src pad type while creating
      and signalling the new pad.
      This fixes a deadlock with RTPBin shutdown lock. These two locks would
      end up being taken in two different order, which caused a deadlock. More
      generally, we should not rely on a streamlock when handling out-of-band
      data, so as a side effect, we should not take a stream lock when
      iterating internal links.
  9. 03 Jun, 2019 5 commits
  10. 29 May, 2019 4 commits
  11. 28 May, 2019 2 commits
  12. 27 May, 2019 1 commit
  13. 26 May, 2019 1 commit
  14. 25 May, 2019 4 commits