1. 06 Jan, 2020 1 commit
  2. 03 Jan, 2020 3 commits
  3. 30 Dec, 2019 2 commits
  4. 25 Dec, 2019 1 commit
  5. 06 Dec, 2019 1 commit
  6. 03 Dec, 2019 1 commit
  7. 29 Nov, 2019 1 commit
  8. 18 Nov, 2019 1 commit
  9. 06 Nov, 2019 1 commit
  10. 15 Aug, 2019 1 commit
  11. 30 Jul, 2019 1 commit
    • Stephan Hilb's avatar
      lavd/v4l2: produce a 0 byte packet when a dequeued buffer's size is unexpected · b761ae07
      Stephan Hilb authored
      Behave like we do for V4L2_BUF_FLAG_ERROR, implemented in commit 28f20d2f .
      
      For some devices (probably also related to the V4L driver implementation)
      it happens that when invoking the ioctl DQBUF, the returned buffer is not
      of the expected size. Here are two examples for such occurrences:
      
          [video4linux2,v4l2 @ 0x258b440] Dequeued v4l2 buffer contains 609596 bytes, but 614400 were expected. Flags: 0x00000001.
          /dev/video1: Invalid data found when processing input
      
          [video4linux2,v4l2 @ 0x225f440] Dequeued v4l2 buffer contains 609508 bytes, but 614400 were expected. Flags: 0x00000001.
          /dev/video1: Invalid data found when processing input
      
      For the ffmpeg CLI tool this means it will stop capturing and exit.
      
      The described behaviour was observed at least with one OmniVision USB
      web cam and with some stk1160 devices.
      
      If you search the web for the error message, you will find quite a few
      instances of this problem. Some of them experienced on other devices.
      
      Probably fixes ticket #4795
      Signed-off-by: 's avatarAlexander Strasser <eclipse7@gmx.net>
      b761ae07
  12. 21 Jul, 2019 2 commits
  13. 08 Jul, 2019 6 commits
  14. 17 May, 2019 1 commit
  15. 05 May, 2019 1 commit
  16. 23 Apr, 2019 1 commit
  17. 15 Apr, 2019 3 commits
  18. 10 Apr, 2019 1 commit
  19. 06 Apr, 2019 1 commit
    • Octavio Alvarez's avatar
      lavd/x11grab: fix vertical repositioning · f4f40cbb
      Octavio Alvarez authored
      There is a calculation error in xcbgrab_reposition() that breaks
      vertical repositioning on follow_mouse. It made the bottom
      reposition occur when moving the mouse lower than N pixels after
      the capture bottom edge, instead of before.
      
      This commit fixes the calculation to match the documentation.
      
      follow_mouse: centered or number of pixels. The documentation says:
      
      When it is specified with "centered", the grabbing region follows
      the mouse pointer and keeps the pointer at the center of region;
      otherwise, the region follows only when the mouse pointer reaches
      within PIXELS (greater than zero) to the edge of region.
      f4f40cbb
  20. 23 Mar, 2019 1 commit
  21. 22 Mar, 2019 1 commit
  22. 20 Mar, 2019 1 commit
  23. 30 Jan, 2019 2 commits
  24. 15 Jan, 2019 1 commit
  25. 03 Jan, 2019 1 commit
  26. 10 Dec, 2018 1 commit
  27. 01 Dec, 2018 1 commit
  28. 01 Nov, 2018 1 commit