1. 15 Feb, 2018 5 commits
  2. 14 Feb, 2018 3 commits
  3. 08 Feb, 2018 1 commit
  4. 03 Feb, 2018 2 commits
  5. 02 Feb, 2018 1 commit
  6. 01 Feb, 2018 1 commit
  7. 31 Jan, 2018 3 commits
  8. 30 Jan, 2018 1 commit
  9. 27 Jan, 2018 3 commits
  10. 26 Jan, 2018 1 commit
  11. 23 Jan, 2018 4 commits
  12. 20 Jan, 2018 1 commit
  13. 18 Jan, 2018 6 commits
  14. 16 Jan, 2018 1 commit
    • Edward Hervey's avatar
      gstpad: Avoid stream-dead-lock on deactivation · 31383e44
      Edward Hervey authored and Edward Hervey's avatar Edward Hervey committed
      The following case can happen when two thread try to activate and
      deactivate a pad at the same time:
      T1: starts to deactivate, calls pre_activate(), sets in_activation
          to TRUE and carries on
      T2: starts to activate, calls pre_activate(), in_activation is TRUE
          so it waits on the GCond
      T1: calls post_activate(), tries to acquire the streaming lock ..
          but can't because T2 is currently holding it
      
      With this patch, the deadlock will no longer happen but does not
      solve the problem that:
      T2: will resume activation of the pad, set the pad mode to the target
         one (PUSH or PULL) and eventually the streaming lock gets released.
      T1: is able to finish calling post_activate() ... but ... the pad
         wasn't deactivated (T2 was the last one to "activate" the pad.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=792341
      31383e44
  15. 15 Jan, 2018 2 commits
  16. 12 Jan, 2018 1 commit
  17. 11 Jan, 2018 4 commits