1. 21 Feb, 2017 3 commits
  2. 20 Feb, 2017 1 commit
  3. 19 Feb, 2017 2 commits
  4. 07 Feb, 2017 1 commit
  5. 31 Jan, 2017 1 commit
  6. 30 Jan, 2017 3 commits
  7. 27 Jan, 2017 4 commits
  8. 26 Jan, 2017 1 commit
  9. 25 Jan, 2017 3 commits
  10. 19 Jan, 2017 3 commits
  11. 18 Jan, 2017 1 commit
    • Arnaud Vrac's avatar
      souphttpsrc: properly track redirections · 780c99fb
      Arnaud Vrac authored
      The current code configures libsoup to handle redirections
      transparently, without informing the caller, thus preventing the element
      to record the redirect code and location uri.
      
      Fix this by always setting the SOUP_MESSAGE_NO_REDIRECT, preventing
      libsoup from handling the redirection. When we receive a redirection
      request and libsoup can safely handle it, return a custom error which
      triggers a retry with the new URI.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=777222
      780c99fb
  12. 16 Jan, 2017 3 commits
  13. 09 Jan, 2017 2 commits
  14. 08 Jan, 2017 1 commit
  15. 22 Dec, 2016 3 commits
  16. 13 Dec, 2016 3 commits
  17. 07 Dec, 2016 2 commits
  18. 05 Dec, 2016 3 commits
    • Edward Hervey's avatar
      jitterbuffer: Don't leak duplicate items · 5f4a8948
      Edward Hervey authored
      When providing items with a seqnum, there is a (very small) probability
      that an element with the same seqnum already exists. Don't forget
      to free that item if it wasn't inserted.
      
      And avoid returning undefined values when dealing with duplicate items
      5f4a8948
    • Håvard Graff's avatar
      rtpjitterbuffer: fix timer-reuse bug · 6907ba94
      Håvard 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
      6907ba94
    • Håvard Graff's avatar
      rtpjitterbuffer: fix lost-event using dts instead of pts · 5db8ce66
      Håvard 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).
      5db8ce66