1. 15 Jan, 2012 1 commit
  2. 11 Jan, 2012 2 commits
  3. 09 Jan, 2012 1 commit
  4. 07 Jan, 2012 1 commit
  5. 05 Jan, 2012 2 commits
  6. 27 Dec, 2011 1 commit
  7. 20 Dec, 2011 1 commit
  8. 19 Dec, 2011 1 commit
  9. 14 Dec, 2011 4 commits
  10. 13 Dec, 2011 1 commit
  11. 11 Dec, 2011 1 commit
  12. 05 Dec, 2011 1 commit
  13. 01 Dec, 2011 1 commit
  14. 27 Nov, 2011 1 commit
  15. 21 Nov, 2011 1 commit
  16. 17 Nov, 2011 2 commits
  17. 11 Nov, 2011 1 commit
  18. 08 Nov, 2011 1 commit
  19. 04 Nov, 2011 2 commits
  20. 31 Oct, 2011 1 commit
  21. 24 Oct, 2011 3 commits
  22. 20 Oct, 2011 1 commit
  23. 16 Oct, 2011 4 commits
    • Jean First's avatar
      72776adf
    • Marton Balint's avatar
      ffplay: add delay multiple times to frame_timer if it is less than current time · abb0e4f6
      Marton Balint authored
      If the picture queue is empty, or when the calculated delay is 0, frame_timer
      is not increased but we are still displaying the old frame. When we eventually
      get a frame, where the computed delay is positive, so we don't need to drop any
      more frames, then it is best to update frame_timer to be as near as the current
      time as it can.
      
      This way we dont't have to wait several frames to add the necesarry delays to
      frame_timer to reach current time, therefore there are no extra frame drops
      after reaching a positive delay.
      Signed-off-by: 's avatarMarton Balint <cus@passwd.hu>
      abb0e4f6
    • Marton Balint's avatar
      ffplay: remove early frame drop functionality · d2d8e1e5
      Marton Balint authored
      The current impementation of early frame drops (dropping frames before adding
      them to the picture queue) has multiple problems:
      
      Even after gettin A-V sync, the frame droping continues until
      VideoState->skip_frames reaches 1, which can take a lot of time causing useless
      additional frame drops and bad AV-sync. This issue can be easily triggered with
      for example changing the audio stream.
      
      Also video_refresh currenly does not handle early skipped frames in every case,
      for example if we skip a frame, then the last frame duration calculation will
      compute the duration of the sum of the skipped frame and the duration of the
      frame before that, and in compute_target_delay we may multiply this unusually
      big delay.
      Signed-off-by: 's avatarMarton Balint <cus@passwd.hu>
      d2d8e1e5
    • Marton Balint's avatar
      ffplay: calculate target clock dynamically, make code more readable · 4e268aae
      Marton Balint authored
      Since target clock is based on the current A-V delay, it is better calculate it
      when we actually need it rather than when we put a picture in the picture
      queue.
      
      The patch also makes a code a bit more readable by renaming some delay
      variables to duration, and converting compute_target_time to a delay
      calculating function which does not modify the state. Factoring out the
      iteration of the pictq to standalone function is also done in this patch.
      Signed-off-by: 's avatarMarton Balint <cus@passwd.hu>
      4e268aae
  24. 02 Oct, 2011 4 commits
  25. 28 Sep, 2011 1 commit