1. 07 Nov, 2018 4 commits
    • Jan Schmidt's avatar
      segment: Allow stop == -1 in gst_segment_to_running_time() and rate < 0 · 6b2bbd60
      Jan Schmidt authored
      If a segment has stop == -1, then gst_segment_to_running_time()
      would refuse to calculate a running time for negative rates,
      but gst_segment_do_seek() allows this scenario and uses a
      valid duration for calculations.
      
      Make the 2 functions consistent by using any configured duration
      to calculate a running time too in that case.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=796559
      6b2bbd60
    • Edward Hervey's avatar
      multiqueue: Don't clamp running times for position calculation · 36d19e7e
      Edward Hervey authored
      Since we use full signed running times, we no longer need to clamp
      the buffer time.
      
      This avoids having the position of single queues not advancing for
      buffers that are out of segment and never waking up non-linked
      streams (resulting in an apparent "deadlock").
      36d19e7e
    • Jan Schmidt's avatar
      ptp clock: Increase tolerance for late follow-up and delay-resp · 8e328f57
      Jan Schmidt authored
      The follow-up and delay-resp messages carry precise
      timestamps for the arrival at the clock master, but
      the local return time is unimportant, so we should be very
      lenient in accepting them late. Some PTP masters don't
      prioritise sending those packets, and we reject all the
      responses and never sync - or take forever to do so.
      
      Increase the tolerance to 20x the mean path delay.
      
      Also fix a typo in one debug output that would print
      the absolute time of the delay-resp message, not the offset
      from the delay-req that it's actually being compared against.
      8e328f57
    • Jan Schmidt's avatar
      ptp clock: Wait for ANNOUNCE before selecting a master · 9dafa0cb
      Jan Schmidt authored
      Previously, with opportunistic sync we'd track a master
      clock as soon as we see a SYNC message, and hence sync up
      faster, but then we'd announce we're synched before seeing
      the ANNOUNCE, leaving the clock details like grandmaster-clock
      empty.
      
      A better way is to start tracking the clock opportunistically,
      but not announce we're synched until we've also seen the ANNOUNCE.
      9dafa0cb
  2. 05 Nov, 2018 1 commit
  3. 22 Oct, 2018 1 commit
    • Edward Hervey's avatar
      queue2: Reset result flow when retrying · e486a924
      Edward Hervey authored
      If we ever get a GST_FLOW_EOS from downstream, we might retry
      pushing new data. But if pushing that data doesn't return a
      GstFlowReturn (such as pushing events), we would end up returning
      the previous GstFlowReturn (i.e. EOS).
      
      Not properly resetting it would cause cases where queue2 would
      stop pushing on the first GstEvent stored (even if there is more
      data contained within).
      e486a924
  4. 02 Oct, 2018 2 commits
  5. 17 Sep, 2018 1 commit
  6. 16 Sep, 2018 2 commits
  7. 11 Sep, 2018 2 commits
  8. 08 Sep, 2018 1 commit
  9. 03 Sep, 2018 1 commit
  10. 31 Aug, 2018 6 commits
  11. 02 Aug, 2018 5 commits
  12. 30 Jul, 2018 1 commit
  13. 25 Jul, 2018 1 commit
  14. 19 Jul, 2018 3 commits
  15. 18 Jul, 2018 1 commit
  16. 21 May, 2018 1 commit
  17. 20 May, 2018 1 commit
  18. 17 May, 2018 3 commits
  19. 14 May, 2018 1 commit
  20. 08 May, 2018 1 commit
  21. 05 May, 2018 1 commit