Skip to content
Snippets Groups Projects
  1. Sep 01, 2016
  2. Aug 31, 2016
  3. Aug 30, 2016
    • Edward Hervey's avatar
      multiqueue: Fix high_time wakeup logic · 3117525c
      Edward Hervey authored
      When calculating the high_time, cache the group value in each singlequeue.
      
      This fixes the issue by which wake_up_next_non_linked() would use the global
      high-time to decide whether to wake-up a waiting thread, instead of the group
      one, resulting in those threads constantly spinning.
      
      Tidy up a bit the waiting logic while we're at it.
      
      With this patch, we go from 212% playing a 8 audio / 8 video file down to less
      than 10% (most of it being the video decoding).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=770225
      3117525c
  4. Aug 28, 2016
    • Tim-Philipp Müller's avatar
      tools: gst-inspect: don't print internal pad request function name · 3cae9335
      Tim-Philipp Müller authored
      This just confuses people, they look at it and try to call it
      directly by name, instead of using the public GstElement API.
      It stands to reason that it goes without saying that when an
      element provides request pads that they can actually be
      requested using the standard API, and there's no point in
      printing internal implementation details of the element.
      3cae9335
  5. Aug 27, 2016
  6. Aug 26, 2016
  7. Aug 25, 2016
  8. Aug 23, 2016
  9. Aug 22, 2016
  10. Aug 21, 2016
  11. Aug 19, 2016
  12. Aug 13, 2016
  13. Aug 12, 2016
    • Edward Hervey's avatar
      queue2: Post buffering messages earlier in ringbuffer mode · 5154dcfb
      Edward Hervey authored
      In ringbuffer mode we need to make sure we post buffering messages *before*
      blocking to wait for data to be drained.
      
      Without this, we would end up in situations like this:
      * pipeline is pre-rolling
      * Downstream demuxer/decoder has pushed data to all sinks, and demuxer thread
        is blocking downstream (i.e. not pulling from upstream/queue2).
      * Therefore pipeline has pre-rolled ...
      * ... but queue2 hasn't filled up yet, therefore the application waits for
        the buffering 100% messages before setting the pipeline to PLAYING
      * But queue2 can't post that message, since the 100% message will be posted
        *after* there is room available for that last buffer.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=769802
      5154dcfb
  14. Aug 08, 2016
  15. Jul 25, 2016
  16. Jul 24, 2016
  17. Jul 22, 2016
  18. Jul 20, 2016
Loading