1. 02 Jul, 2019 4 commits
  2. 01 Jul, 2019 1 commit
  3. 28 Jun, 2019 1 commit
  4. 26 Jun, 2019 1 commit
  5. 24 Jun, 2019 4 commits
  6. 19 Jun, 2019 4 commits
  7. 18 Jun, 2019 2 commits
    • Sebastian Dröge's avatar
      rtpgstpay: Send caps anyway if caps are pending in the adapter but are different from the new ones · b18ad8b5
      Sebastian Dröge authored
      Otherwise it can happen that we receive a caps event, then another caps
      event and only then buffers. We would then send out the first caps event
      in the stream but mark buffers with the caps version of the second caps
      event.
      b18ad8b5
    • Sebastian Dröge's avatar
      rtpgstdepay: Only store the current caps and drop old caps immediately · 44a697de
      Sebastian Dröge authored
      Otherwise it can happen that we already collected 7 caps, miss the 8th
      caps packet (packet loss) and then re-use the 1st caps for the following
      buffers instead of the 8th caps which will likely cause errors further
      downstream unless both caps are accidentally the same.
      
      Keeping old caps around does not seem to have any value other than
      potentially causing errors. We would always receive new caps whenever
      they change (even if they were previous ones) and it's very unlikely
      that they happen to be exactly the same as the previous ones.
      
      Also after having received new caps or a buffer with a next caps
      version, no buffers with old caps version will arrive anymore.
      44a697de
  8. 16 Jun, 2019 2 commits
  9. 14 Jun, 2019 2 commits
  10. 13 Jun, 2019 2 commits
  11. 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.)
      6269ed49
    • 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
      broken.
      
      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.
      8ed7ab17
    • Håvard Graff's avatar
      rtpjitterbuffer: fix unused variables · dd422f0b
      Håvard Graff authored
      dd422f0b
  12. 11 Jun, 2019 4 commits
  13. 06 Jun, 2019 2 commits
  14. 05 Jun, 2019 5 commits
  15. 04 Jun, 2019 2 commits