Skip to content
GitLab
Switch branch/tag
  1. 18 Nov, 2016 5 commits
  3. 17 Nov, 2016 3 commits
  5. 16 Nov, 2016 1 commit
  7. 15 Nov, 2016 2 commits
  9. 14 Nov, 2016 4 commits
  11. 12 Nov, 2016 2 commits
  13. 11 Nov, 2016 1 commit
  15. 10 Nov, 2016 2 commits
  17. 08 Nov, 2016 1 commit
  19. 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
  21. 03 Nov, 2016 2 commits
  23. 02 Nov, 2016 5 commits
  25. 01 Nov, 2016 9 commits