1. 23 Apr, 2015 1 commit
  2. 30 Mar, 2015 1 commit
    • Thomas Guillem's avatar
      video_output: fix controls and events not processed · 93e1d6ad
      Thomas Guillem authored
      This issue is easily reproducible with VDPAU activated, with a 60fps ts file,
      see #14199.
      
      With this sample, The video_output Thread is looping in ThreadDisplayPicture
      way more often than with other videos. Consequently, vout_ManageWrapper and
      ThreadControl are not called enough. As a result, subtitles are processed too
      late, the mouse isn't able to hide/unhide, we can be stuck in fullscreen mode,
      or second click on video to pop up the menu doesn't work.
      
      To fix this issue: don't loop in ThreadDisplayPicture and don't wait in
      vout_control_Pop if a picture was previously displayed.
      
      Fixes #14199
      Signed-off-by: Jean-Baptiste Kempf's avatarJean-Baptiste Kempf <jb@videolan.org>
      93e1d6ad
  3. 07 Feb, 2015 1 commit
  4. 01 Nov, 2014 9 commits
  5. 30 Oct, 2014 1 commit
  6. 29 Oct, 2014 1 commit
  7. 26 Oct, 2014 1 commit
  8. 23 Oct, 2014 1 commit
  9. 16 Oct, 2014 14 commits
  10. 11 Oct, 2014 1 commit
  11. 12 Sep, 2014 1 commit
    • Felix Abecassis's avatar
      vout: fix a deadlock with the picture pool lock · 22c80ce3
      Felix Abecassis authored
      A deadlock could occur in an high load situation where the vout and
      the decoder are taking excessive amounts of time.
      
      The vout thread repeatedly call ThreadDisplayPicture in its main loop
      until it returns an error, while keeping the picture pool locked. If
      no picture was recently received, the vout will redisplay the current
      picture (a "refresh") by calling ThreadDisplayRenderPicture with
      is_forced=true. If this refresh is excessively long, the vout thread
      will be stuck in a refresh loop. The decoder cannot make any progress
      since the picture pool lock is hold and the vout won't be polling for
      control commands, yielding a total deadlock of the program.
      
      This situation can be reproduced artificially by sleeping in the
      decoder and decreasing variable VOUT_REDISPLAY_DELAY.
      
      A simple solution to this issue is to exit the ThreadDisplayPicture
      loop after refreshing. Since a refresh typically occurs when no new
      pictures are received from the decoder, this should not decrease
      performance.
      22c80ce3
  12. 01 Sep, 2014 1 commit
  13. 28 Jul, 2014 2 commits
  14. 14 Mar, 2014 1 commit
  15. 13 Mar, 2014 2 commits
  16. 17 Jan, 2014 1 commit
  17. 05 Jan, 2014 1 commit