1. 08 May, 2019 1 commit
  2. 03 Nov, 2018 1 commit
  3. 16 Jul, 2018 1 commit
  4. 13 Jul, 2018 1 commit
  5. 07 Jul, 2018 1 commit
    • Olivier Crête's avatar
      basesink: Add processing deadline · a7f9c802
      Olivier Crête authored
      The processing deadline is the acceptable amount of time to process the media
      in a live pipeline before it reaches the sink. This is on top of the algorithmic
      latency that is normally reported by the latency query. This should make
      pipelines such as "v4lsrc ! xvimagesink" not claim that all frames are late
      in the QoS events. Ideally, this should replace max_lateness for most applications.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=640610
      a7f9c802
  6. 24 Jun, 2018 1 commit
  7. 01 May, 2018 1 commit
  8. 16 Feb, 2018 1 commit
  9. 05 Oct, 2017 1 commit
  10. 14 Jul, 2017 1 commit
  11. 09 Jul, 2017 1 commit
  12. 15 Feb, 2017 1 commit
  13. 27 Jan, 2017 1 commit
  14. 17 Dec, 2016 1 commit
  15. 23 Nov, 2016 1 commit
  16. 03 Nov, 2016 2 commits
  17. 02 Nov, 2016 4 commits
  18. 15 Sep, 2016 1 commit
  19. 08 Sep, 2016 1 commit
    • Sebastian Dröge's avatar
      basesink: Use the average durations based on timestamps for the QoS proportion... · c1bd6677
      Sebastian Dröge authored
      basesink: Use the average durations based on timestamps for the QoS proportion when doing trickmodes
      
      The durations of the buffers are (usually) assuming that no frames are being
      dropped and are just the durations coming from the stream. However if we do
      trickmodes, frames are being dropped regularly especially if only key units
      are supposed to be played.
      
      Fixes completely bogus QoS proportion values in the above case.
      c1bd6677
  20. 27 Aug, 2016 1 commit
  21. 13 Jun, 2016 1 commit
    • Sebastian Dröge's avatar
      basesink: Update start time when losing state only if we were in PLAYING · b9a4a2a9
      Sebastian Dröge authored
      If we were in PAUSED, the current clock time and base time don't have much to
      do with the running time anymore as the clock might have advanced while we
      were PAUSED. The system clock does that for example, audio clocks often don't.
      
      Updating the start time in PAUSED will cause a) the wrong position to be
      reported, b) step events to step not just the requested amount but the amount
      of time we spent in PAUSED. The start time should only ever be updated when
      going from PLAYING to PAUSED to remember the current running time (to be able
      to compensate later when going to PLAYING for the clock time advancing while
      PAUSED), not when we are already in PAUSED.
      
      Based on a patch by Kishore Arepalli <kishore.arepalli@gmail.com>
      
      The updating of the start time when the state is lost was added in commit
      ba943a82 to fix the position reporting when
      the state is lost. This still works correctly after this change.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=739289
      b9a4a2a9
  22. 15 May, 2016 1 commit
  23. 12 Apr, 2016 2 commits
  24. 24 Mar, 2016 1 commit
  25. 15 Feb, 2016 1 commit
  26. 25 Sep, 2015 1 commit
  27. 05 Aug, 2015 1 commit
  28. 06 Jul, 2015 1 commit
  29. 24 Jun, 2015 1 commit
  30. 22 Jun, 2015 2 commits
  31. 25 May, 2015 1 commit
  32. 14 May, 2015 1 commit
  33. 14 Mar, 2015 1 commit
  34. 13 Mar, 2015 1 commit