Skip to content
Snippets Groups Projects
  1. Sep 24, 2014
  2. Sep 23, 2014
  3. Sep 22, 2014
  4. Sep 19, 2014
  5. Sep 17, 2014
  6. Sep 16, 2014
  7. Sep 12, 2014
  8. Sep 11, 2014
  9. Sep 04, 2014
  10. Aug 28, 2014
    • Thibault Saunier's avatar
      multiqueue: Not post BUFFERING message if one of the singlequeue doesn't need it · 03d93e7c
      Thibault Saunier authored and Sebastian Dröge's avatar Sebastian Dröge committed
      Imagine the following 'pipeline'
      
                      --------------
                  p1/| 'fullqueue'  |--- 'laggy' downstream
        ---------  / |              |
      -| demuxer |   | multiqueue   |
        ---------  \ |              |
                  p2\| 'emptyqueue' |--- 'fast' downstream
                      --------------
      
      In the case downstream of one single queue (fullqueue) has (a lot of) latency
      (for example for reverse playback with video), we can end up having the other
      SingleQueue (emptyqueue) emptied, before that fullqueue gets
      unblocked. In the meantime, the demuxer tries to push on fullqueue, and
      is blocking there.
      
      In that case the current code will post a BUFFERING message on the bus when
      emptyqueue gets emptied, that leads to the application setting the pipeline state to
      PAUSED. So now we end up in a situation where 'laggy downstream' is
      prerolled and will not unblock anymore because the pipeline is set to
      PAUSED, the fullequeue does not have a chance to be emptied and
      the emptyqueue can not get filled anymore so no more BUFERRING message
      will be posted and the pipeline is stucked in PAUSED for the eternity.
      
      Making sure that we do not try to "buffer" if one of the single queue
      does not need buffering, prevents this situtation from happening though it lets the
      oportunity for buffering in all other cases.
      
      That implements a new logic where we need all singlequeue to need
      buffering for the multiqueue to actually state buffering is needed,
      taking the maximum buffering of the single queue as the reference point.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=734412
      03d93e7c
    • Arnaud Vrac's avatar
      buffer: do not touch memory tag flag when copying buffer flags · efa5a41d
      Arnaud Vrac authored and Sebastian Dröge's avatar Sebastian Dröge committed
      The tag memory flag will be set later if the memory is also copied. This
      patch avoids buffers being freed needlessly in bufferpools.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=735574
      efa5a41d
  11. Aug 27, 2014
  12. Aug 23, 2014
    • Tim-Philipp Müller's avatar
      queue: fix race when flush-stop event comes in whilst shutting down · 902a5e6b
      Tim-Philipp Müller authored
      Don't re-start the queue push task on the source pad when a
      flush-stop event comes in and we're in the process of shutting
      down, otherwise that task will never be stopped again.
      
      When the element is set to READY state, the pads get de-activated.
      The source pad gets deactivated before the queue's own activate_mode
      function on the source pads gets called (which will stop the thread),
      so checking whether the pad is active before re-starting the task on
      receiving flush-stop should be fine. The problem would happen when the
      flush-stop handler was called just after the queue's activate mode
      function had stopped the task.
      
      Spotted and debugged by Linus Svensson <linux.svensson@axis.com>
      
      https://bugzilla.gnome.org/show_bug.cgi?id=734688
      902a5e6b
    • Thiago Santos's avatar
      inputselector: always proxy caps query · ffa14610
      Thiago Santos authored and Tim-Philipp Müller's avatar Tim-Philipp Müller committed
      Otherwise it would only be proxied for the active pad which can lead
      upstream to use an incompatible caps for the downstream element.
      
      Even if a reconfigure event is sent upstream when the pad is activated, this
      will save the caps reconfiguration if it is already using an acceptable caps.
      ffa14610
  13. Aug 14, 2014
  14. Aug 13, 2014
  15. Aug 11, 2014
    • Руслан Ижбулатов's avatar
      poll: Prevent false-negative from WAKE_EVENT() on W32 · 067604b2
      Руслан Ижбулатов authored and Sebastian Dröge's avatar Sebastian Dröge committed
      SetEvent() seems to not call SetLastError(0) internally, so checking last
      error after calling SetEvent() may return the error from an earlier W32 API
      call. Fix this by calling SetlastError(0) explicitly.
      
      Currently WAKE_EVENT() code is cramped into a macro and doesn't look to be
      entirely correct. Particularly, it does not check the return value of
      SetEvent(), only the thread-local W32 error value. It is likely that SetEvent()
      actually just returns non-zero value, but the code mistakenly thinks that the
      call has failed, because GetLastError() seems to indicate so.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=733805
      067604b2
  16. Jul 30, 2014
  17. Jul 28, 2014
Loading