1. 14 Mar, 2017 1 commit
  2. 09 Mar, 2017 1 commit
  3. 03 Mar, 2017 1 commit
  4. 28 Feb, 2017 1 commit
  5. 27 Feb, 2017 2 commits
  6. 21 Feb, 2017 1 commit
  7. 14 Feb, 2017 1 commit
  8. 25 Jan, 2017 1 commit
  9. 24 Jan, 2017 1 commit
  10. 09 Jan, 2017 1 commit
  11. 02 Jan, 2017 2 commits
    • Jan Schmidt's avatar
      splitmuxsink: Add format-location-full signal · f7009eb5
      Jan Schmidt authored
      Add a new signal for formatting the filename, which receives
      a GstSample containing the first buffer from the reference
      stream that will be muxed into that file.
      
      Useful for creating filenames that are based on the
      running time or other attributes of the buffer.
      
      To make it work, opening of files and setting filenames is
      now deferred until there is some data to write to it,
      which also requires some changes to how async state changes
      and gap events are handled.
      f7009eb5
    • Edward Hervey's avatar
      check: Remove dead code · 3a4d4dcd
      Edward Hervey authored
      3a4d4dcd
  12. 21 Dec, 2016 1 commit
  13. 14 Dec, 2016 1 commit
    • Havard Graff's avatar
      tests/jitterbuffer: Major refactoring and cleanups · 0a81f71d
      Havard Graff authored
      * Changed PCMU->TEST for common macros
      * Changed verify-functions (lost & rtx) into macros.
      * Remove option to add marker-bit for test-buffers (not used anywhere)
      * Add new push_test_buffer function that makes sure there are correlation
        between dts and the time on the clock. (classic test-mistake)
      * Established a generic starting-point for tests with the
        construct_deterministic_initial_state function and use it where
        applicable, which removes lots of "boilerplate" everywhere.
      * Add basic lost-event test
      * Remove as much "magic constants" as possible.
      * Remove 3 tests that no longer are testing anything that others don't,
        and was completely unmaintainable.
      * Remove unnecessary use of the testclock
      * Verify each test is testing what it actually says it does (and modify
        where it doesn't)
      
      In general, make the tests much smaller, better, more maintainable and
      readable.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=774409
      0a81f71d
  14. 13 Dec, 2016 1 commit
  15. 16 Nov, 2016 1 commit
  16. 04 Nov, 2016 3 commits
    • Havard Graff's avatar
      rtpjitterbuffer: fix timer-reuse bug · 1a4393fb
      Havard Graff authored
      When doing rtx, the jitterbuffer will always add an rtx-timer for the next
      sequence number.
      
      In the case of the packet corresponding to that sequence number arriving,
      that same timer will be reused, and simply moved on to wait for the
      following sequence number etc.
      
      Once an rtx-timer expires (after all retries), it will be rescheduled as
      a lost-timer instead for the same sequence number.
      
      Now, if this particular sequence-number now arrives (after the timer has
      become a lost-timer), the reuse mechanism *should* now set a new
      rtx-timer for the next sequence number, but the bug is that it does
      not change the timer-type, and hence schedules a lost-timer for that
      following sequence number, with the result that you will have a very
      early lost-event for a packet that might still arrive, and you will
      never be able to send any rtx for this packet.
      
      Found by Erlend Graff - erlend@pexip.com
      
      https://bugzilla.gnome.org/show_bug.cgi?id=773891
      1a4393fb
    • Havard Graff's avatar
      rtpjitterbuffer: fix lost-event using dts instead of pts · fb9c75db
      Havard Graff authored
      The lost-event was using a different time-domain (dts) than the outgoing
      buffers (pts). Given certain network-conditions these two would become
      sufficiently different and the lost-event contained timestamp/duration
      that was really wrong. As an example GstAudioDecoder could produce
      a stream that jumps back and forth in time after receiving a lost-event.
      
      The previous behavior calculated the pts (based on the rtptime) inside the
      rtp_jitter_buffer_insert function, but now this functionality has been
      refactored into a new function rtp_jitter_buffer_calculate_pts that is
      called much earlier in the _chain function to make pts available to
      various calculations that wrongly used dts previously
      (like the lost-event).
      
      There are however two calculations where using dts is the right thing to
      do: calculating the receive-jitter and the rtx-round-trip-time, where the
      arrival time of the buffer from the network is the right metric
      (and is what dts in fact is today).
      
      The patch also adds two tests regarding B-frames or the
      “rtptime-going-backwards”-scenario, as there were some concerns that this
      patch might break this behavior (which the tests shows it does not).
      fb9c75db
    • Havard Graff's avatar
      rtpjitterbuffer: fix bug in reschedule_timer · bea35f97
      Havard Graff authored
      The new timeout is always going to be (timeout + delay), however, the
      old behavior compared the current timeout to just (timeout), basically
      being (delay) off.
      
      This would happen if rtx-delay == rtx-retry-timeout, with the result that
      a second rtx attempt for any buffers would be scheduled immediately instead
      of after rtx-delay ms.
      
      Simply calculate (new_timeout = timeout + delay) and then use that instead.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=773905
      bea35f97
  17. 03 Nov, 2016 1 commit
  18. 01 Nov, 2016 1 commit
  19. 25 Oct, 2016 1 commit
  20. 23 Oct, 2016 1 commit
  21. 21 Oct, 2016 1 commit
  22. 20 Oct, 2016 3 commits
  23. 11 Oct, 2016 1 commit
  24. 06 Oct, 2016 1 commit
  25. 30 Sep, 2016 2 commits
  26. 27 Sep, 2016 1 commit
  27. 26 Sep, 2016 2 commits
  28. 15 Sep, 2016 1 commit
  29. 14 Sep, 2016 4 commits
    • Havard Graff's avatar
      rtpjitterbuffer: improved rtx-rtt averaging · f440b074
      Havard Graff authored
      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
      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
      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
      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