1. 16 Jun, 2019 1 commit
  2. 14 Jun, 2019 2 commits
  3. 13 Jun, 2019 2 commits
  4. 12 Jun, 2019 3 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
  5. 11 Jun, 2019 4 commits
  6. 06 Jun, 2019 2 commits
  7. 05 Jun, 2019 3 commits
    • Mart Raudsepp's avatar
      qtdemux: Provide a 2 frames lead-in for audio decoders · cbfa4531
      Mart Raudsepp authored
      AAC and various other audio codecs need a couple frames of lead-in to
      decode it properly. The parser elements like aacparse take care of it
      via gst_base_parse_set_frame_rate, but when inside a container, the
      demuxer is doing the seek segment handling and never gives lead-in
      data downstream.
      Handle this similar to going back to a keyframe with video, in the
      same place. Without a lead-in, the start of the segment is silence,
      when it shouldn't, which becomes especially evident in NLE use cases.
      cbfa4531
    • Mart Raudsepp's avatar
      qtdemux: remove indent exception and reindent · 9b348e75
      Mart Raudsepp authored
      As the indent disabling isn't playing along for a following fix,
      remove the indent disabling and reindent in a way that doesn't
      look too stupid.
      9b348e75
    • Aaron Boxer's avatar
      7bd1909f
  8. 04 Jun, 2019 1 commit
    • 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.
      f7c712d0
  9. 03 Jun, 2019 2 commits
  10. 29 May, 2019 2 commits
  11. 28 May, 2019 2 commits
  12. 27 May, 2019 1 commit
  13. 26 May, 2019 1 commit
  14. 25 May, 2019 3 commits
  15. 24 May, 2019 1 commit
  16. 22 May, 2019 1 commit
  17. 17 May, 2019 1 commit
    • Nicolas Dufresne's avatar
      rtpsession: Always keep at least one NACK on early RTCP · 947a37f3
      Nicolas Dufresne authored
      We recently added code to remove outdate NACK to avoid using bandwidth
      for packet that have no chance of arriving on time. Though, this had a
      side effect, which is that it was to get an early RTCP packet with no
      feedback into it. This was pretty useless but also had a side effect,
      which is that the RTX RTT value would never be updated. So we we stared
      having late RTX request due to high RTT, we'd never manage to recover.
      
      This fixes the regression by making sure we keep at least one NACK in
      this situation. This is really light on the bandwidth and allow for
      quick recover after the RTT have spiked higher then the jitterbuffer
      capacity.
      947a37f3
  18. 13 May, 2019 4 commits
  19. 03 May, 2019 1 commit
  20. 02 May, 2019 2 commits
    • Nicolas Dufresne's avatar
      a6e7f258
    • Nicolas Dufresne's avatar
      rtpsession: Call on-new-ssrc earlier · 84c102b6
      Nicolas Dufresne authored
      Right now, we may call on-new-ssrc after we have processed the first
      RTP packet. This prevents properly configuring the source as some
      property like "probation" are copied internally for use as a
      decreasing counter. For this specific property, it prevents the
      application from disabling probation on auxiliary sparse stream.
      
      Probation is harmful on sparse streams since the probation algorithm
      assume frequent and contiguous RTP packets.
      84c102b6
  21. 01 May, 2019 1 commit