- 30 Apr, 2018 2 commits
-
-
Thiago Santini authored
-
Thiago Santini authored
-
- 01 Nov, 2017 1 commit
-
-
Thiago Santini authored
Previously, we had a single usb context for everyone. This was causing the usb context thread handler to be overloaded and signficantly reduced performance (and possibly caused frame corruption?). As of this commit, CPU consumption for uvc devices is greatly reduced (although still not on pair with devices using direct show!). Tested on Windows 8.1 and Windows 10. One issue was observed during tests with this new context setup. Sometimes when reinitializing (e.g., changing the framerate or resolution), the uvc stream will be initialized without errors, but we only receive a single (sometimes corrupted) frame back; afterwards, no new frames are received. Reopening the camera seems to solve the issue, so this is low priority atm.
-
- 28 Aug, 2017 1 commit
-
-
Thiago Santini authored
-
- 21 Apr, 2017 1 commit
-
-
Thiago Santini authored
-
- 28 Mar, 2017 1 commit
-
-
Thiago Santini authored
When using 640x480 @ 120 FPS and the processing can't keep up with the frame rate, some glitches start showing in the images; these commit adds some additional options that were used during test and might be useful in the future. I'm not entirely sure where these glitches come from, but it seems they originate within libuvc. After tracing it back to this point, increasing LIBUVC_NUM_TRANSFER_BUFS seems to get rid of the bug. However, setting it too high impedes opening all three pupil cameras. Temporary solution is to make sure processing can keep up with the framerate (e.g., by downsizing the processing input in EyeRecToo).
-
- 27 Mar, 2017 1 commit
-
-
Thiago Santini authored
-
- 23 Feb, 2017 2 commits
-
-
Thiago Santini authored
When experimenting with multiple cameras on separate threads sometimes uvc_open would return UVC_ERROR_NOT_FOUND.
-
Thiago C. Santini authored
-