1. 26 Sep, 2016 2 commits
  2. 15 Sep, 2016 1 commit
  3. 14 Sep, 2016 7 commits
    • Havard Graff's avatar
      rtpjitterbuffer: improved rtx-rtt averaging · f440b074
      Havard Graff authored and Olivier Crête's avatar Olivier Crête committed
      The basic idea is this:
      1. For *larger* rtx-rtt, weigh a new measurement as before
      2. For *smaller* rtx-rtt, be a bit more conservative and weigh a bit less
      3. For very large measurements, consider them "outliers"
         and count them a lot less
      
      The idea being that reducing the rtx-rtt is much more harmful then
      increasing it, since we don't want to be underestimating the rtt of the
      network, and when using this number to estimate the latency you need for
      you jitterbuffer, you would rather want it to be a bit larger then a bit
      smaller, potentially losing rtx-packets. The "outlier-detector" is there
      to prevent a single skewed measurement to affect the outcome too much.
      On wireless networks, these are surprisingly common.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=769768
      f440b074
    • Stian Selnes's avatar
      rtpjitterbuffer: Detect whether to assume equidistant spacing when loss · f8238f0a
      Stian Selnes authored and Olivier Crête's avatar Olivier Crête committed
      Assuming equidistant packet spacing when that's not true leads to more
      loss than necessary in the case of reordering and jitter. Typically this
      is true for video where one frame often consists of multiple packets
      with the same rtp timestamp. In this case it's better to assume that the
      missing packets have the same timestamp as the last received packet, so
      that the scheduled lost timer does not time out too early causing the
      packets to be considered lost even though they may arrive in time.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=769768
      f8238f0a
    • Stian Selnes's avatar
      rtpjitterbuffer: Don't request rtx if 'now' is past retry period · 2eb73838
      Stian Selnes authored and Olivier Crête's avatar Olivier Crête committed
      There is no need to schedule another EXPECTED timer if we're already
      past the retry period. Under normal operation this won't happen, but if
      there are more timers than the jitterbuffer is able to process in
      real-time, scheduling more timers will just make the situation worse.
      Instead, consider this packet as lost and move on. This scenario can
      occur with high loss rate, low rtt and high configured latency.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=769768
      2eb73838
    • Stian Selnes's avatar
      rtpjitterbuffer: Fix lost duration when gap after lost timer · ab49dfd0
      Stian Selnes authored and Olivier Crête's avatar Olivier Crête committed
      This patch fixes an issue with the estimated gap duration when there is
      a gap immediately after a lost timer has been processed. Previously
      there was a discrepancy beteen the gap in seqnum and gap in dts which
      would cause wrong calculated duration. The issue would only be seen with
      retranmission enabled since when it's disabled lost timers are only
      created when a packet is received and the actual gap length and last dts
      is known.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=769768
      ab49dfd0
    • Havard Graff's avatar
    • Stian Selnes's avatar
      rtpjitterbuffer: Major improvements for RTX stats · 38a75450
      Stian Selnes authored and Olivier Crête's avatar Olivier Crête committed
      Stats should also be collected for unsuccessful packets.
      
      rtx-rtt is very important for determining the necessary configured
      latency on the jitterbuffer. It's especially important to be able to
      increase the latency when retransmitted packets arrive too late and are
      considered lost. This patch includes these late packets in the
      calculation of the various rtx stats, making them more correct and
      useful.
      
      Also in the case where the original packet arrives after a NACK is sent,
      the received RTX packet should update the stats since it provides useful
      information about RTT.
      
      The RTT is only updated if and only if all requested retranmissions are
      received. That way the RTT is guaranteed to make sense. If not we don't
      know which request the packet is a response to and the RTT may be bogus.
      A consequence of this patch is that RTT is not updated for a request
      when one of the RTX packets for that seqnum is lost, but that since
      measured RTT will be more accurate.
      
      The implementation store the RTX information from the timed out timers
      and use this when the retransmitted packet arrives. For performance
      these timers are stored separately from the "normal" timers in order to
      not impact performance (see attached performance test).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=769768
      38a75450
    • Havard Graff's avatar
      rtpjitterbuffer: Add and expose more stats and increase testing of it · 1b868cc9
      Havard Graff authored and Olivier Crête's avatar Olivier Crête committed
      Add num-pushed and num-lost.
      Expose num-late, num-duplicates and avg-jitter.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=769768
      1b868cc9
  4. 01 Sep, 2016 1 commit
  5. 26 Aug, 2016 11 commits
  6. 25 Aug, 2016 1 commit
    • Mikhail Fludkov's avatar
      tests/rtprtx: refactor the tests to use gstharness · 880f4940
      Mikhail Fludkov authored and Olivier Crête's avatar Olivier Crête committed
      The functionality of all the tests was kept exactly the same. Some tests
      were renamed:
      test_push_forward_seq -> test_rtxsend_rtxreceive
      test_drop_one_sender -> test_rtxsend_rtxreceive_with_packet_loss
      test_drop_multiple_sender -> test_multi_rtxsend_rtxreceive_with_packet_loss
      
      test_rtxreceive_data_reconstruction was testing that retransmitted
      buffer produced by rtxsend was correctly transformed to the original
      buffer by rtxreceive. Now we are checking for this in all the tests
      where both rtxsend & rtxreceive are involved. That's why the test was
      removed.
      880f4940
  7. 20 Aug, 2016 1 commit
  8. 18 Aug, 2016 1 commit
  9. 18 Jul, 2016 2 commits
  10. 11 Jul, 2016 2 commits
  11. 07 Jul, 2016 1 commit
  12. 04 Jul, 2016 1 commit
  13. 01 Jul, 2016 1 commit
    • Edward Hervey's avatar
      qtdemux: Handle upstream GAP in push-mode/time segment · e3923df8
      Edward Hervey authored
      This is to handle cases where upstream handles the fragmented streaming in TIME
      segments and sends us data with gaps within fragments. This would happen when dealing
      with trick-modes.
      
      When upstream (push-based, TIME SEGMENT) wishes to send discontinuous samples,
      it must obey the following rules:
      * The buffer containing the [moof] must have a valid GST_BUFFER_OFFSET
      * The buffers containing the first sample after a gap:
       * MUST start at the beginning of a sample,
       * MUST have the DISCONT flag set,
       * MUST have a valid GST_BUFFER_OFFSET relative to the beginning of the fragment.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=767354
      e3923df8
  14. 21 Jun, 2016 5 commits
  15. 11 Jun, 2016 1 commit
  16. 02 Jun, 2016 2 commits