Skip to content
Snippets Groups Projects
  1. Dec 18, 2014
  2. Dec 16, 2014
  3. Dec 11, 2014
  4. Nov 28, 2014
  5. Nov 23, 2014
    • 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
  6. Nov 20, 2014
  7. Nov 15, 2014
    • Vincent Penquerc'h's avatar
      pad: fail dropped queries · 4d7b9a91
      Vincent Penquerc'h authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      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 and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      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
  8. Nov 06, 2014
  9. Oct 24, 2014
  10. Oct 14, 2014
  11. Sep 24, 2014
  12. Sep 23, 2014
  13. Sep 22, 2014
  14. Sep 19, 2014
  15. Sep 17, 2014
Loading