1. 07 Jun, 2015 1 commit
  2. 02 Jun, 2015 3 commits
  3. 24 Apr, 2015 1 commit
  4. 23 Apr, 2015 11 commits
  5. 10 Apr, 2015 1 commit
  6. 18 Dec, 2014 2 commits
  7. 16 Dec, 2014 1 commit
  8. 11 Dec, 2014 2 commits
  9. 28 Nov, 2014 2 commits
  10. 23 Nov, 2014 2 commits
    • Thiago Santos's avatar
      queue2: percentage is relative to high-percent · cafe1f2f
      Thiago Santos authored
      When comparing percentage values, compare with 0-100 scale as it
      has already been made relative to 0-high_percent, otherwise we mark
      the queue as not buffering and report a 50% to the user. This leads to
      a buffering stall as the user assumes the queue is still buffering but
      it thinks it isn't.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=736969
      cafe1f2f
    • Thiago Santos's avatar
      multiqueue: percentage is an absolute value · 81f13a5a
      Thiago Santos authored
      multiqueue's queues stored percent value is the percentage from 0
      to 100 (max-size-*) and should be compared with the requested limit
      (high_percentage) set by the user and not with 100% to check if
      buffering should stop. Otherwise we are only stopping buffering when the
      queue gets completely full.
      81f13a5a
  11. 20 Nov, 2014 1 commit
  12. 15 Nov, 2014 2 commits
    • Vincent Penquerc'h's avatar
      pad: fail dropped queries · 4d7b9a91
      Vincent Penquerc'h authored
      Previously, dropping a query from a pad probe would deem the
      query succeeded, and the caller might then assume the query's
      results are valid, and thus dereference an invalid object
      such as a GstCaps.
      
      We now assume dropped queries did not succeed. Dropped events
      and buffers are still deemed a success.
      4d7b9a91
    • Haakon Sporsheim's avatar
      task: Fix pause/stop race condition · 050ba7d9
      Haakon Sporsheim authored
      If a task thread is calling pause on it self and the
      controlling/"main" thread stops the task, it could end in a race
      where gst_task_func loops and then checks for paused after the
      controlling thread just changed the task state to stopped.
      Hence the task would actually call func again even though it was
      both paused and stopped.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=740001
      050ba7d9
  13. 06 Nov, 2014 2 commits
  14. 24 Oct, 2014 6 commits
  15. 14 Oct, 2014 3 commits