Describe the bug 🐛
Setting MinimumUpdateIntervalSetting::Custom to Duration::from_secs(1) / FPS (16.66ms for 60 FPS) does not capture at that FPS in practice (that is true for the ::Default value of 16.67ms as well)
On a 60 Hz screen, setting the target interval to 1/60 (~16.66 ms) yielded ~45 real captured FPS (sometimes +2-4). I only achieved a reliable ~60 real captured FPS when using 1/90 (~11.11 ms)
On a 120 Hz screen, using 1/60 improved results but still fell short (~52 FPS). 1/90 got closer (~58 FPS). 1/120 reached ~59 FPS. Increasing the capture rate further helped, but tended to overshoot slightly
Note that a higher minimum update rate on a 60 Hz display does not guarantee a 60 FPS capture. For example, wiggling the mouse over the test video on a 60 Hz monitor with a 1/90 interval produced 78 real captured FPS
So there is no reliable way to set an FPS limit - you either overshoot or undershoot and have to deal with that yourself in your code if you don't use the provided video encoder (I actually don't know how it handles over/under shooting)
True both as of stable 1.5.0 and latest 2.0.0-alpha.7
This very well might be an underlying windows issue that you can't do much about as a library without making a lot of assumptions, but if that's the case the documentation should be updated to reflect that limitation as it is not at all obvious
Expected behavior 📝
Setting the MinimumUpdateIntervalSetting to 1 / FPS actually limits FPS to that exact number without under/overshooting
OS 🤖
Additional context ➕
Tested using full screen MPV with a test pattern video that has a distinct numbered frame flash on screen https://youtu.be/4ZrmHhbA8Sc (you might need to yt-dlp it to get into MPV which is much more reliable at frame delivery). I do 20 seconds of capture and do nothing in the on_frame_arrived callback apart from counting the number of captured frames inside the example Capture struct and checking if we should stop. So it can't be processing overhead. Can provide a reproduction repo (tho it's literally a <10 line change from the provided example - remove encoder, add captured frames counter, and do captured / seconds at the end)
Describe the bug 🐛
Setting
MinimumUpdateIntervalSetting::CustomtoDuration::from_secs(1) / FPS(16.66ms for 60 FPS) does not capture at that FPS in practice (that is true for the::Defaultvalue of 16.67ms as well)On a 60 Hz screen, setting the target interval to 1/60 (~16.66 ms) yielded ~45 real captured FPS (sometimes +2-4). I only achieved a reliable ~60 real captured FPS when using 1/90 (~11.11 ms)
On a 120 Hz screen, using 1/60 improved results but still fell short (~52 FPS). 1/90 got closer (~58 FPS). 1/120 reached ~59 FPS. Increasing the capture rate further helped, but tended to overshoot slightly
Note that a higher minimum update rate on a 60 Hz display does not guarantee a 60 FPS capture. For example, wiggling the mouse over the test video on a 60 Hz monitor with a 1/90 interval produced 78 real captured FPS
So there is no reliable way to set an FPS limit - you either overshoot or undershoot and have to deal with that yourself in your code if you don't use the provided video encoder (I actually don't know how it handles over/under shooting)
True both as of stable
1.5.0and latest2.0.0-alpha.7This very well might be an underlying windows issue that you can't do much about as a library without making a lot of assumptions, but if that's the case the documentation should be updated to reflect that limitation as it is not at all obvious
Expected behavior 📝
Setting the
MinimumUpdateIntervalSettingto 1 / FPS actually limits FPS to that exact number without under/overshootingOS 🤖
Additional context ➕
Tested using full screen MPV with a test pattern video that has a distinct numbered frame flash on screen https://youtu.be/4ZrmHhbA8Sc (you might need to yt-dlp it to get into MPV which is much more reliable at frame delivery). I do 20 seconds of capture and do nothing in the on_frame_arrived callback apart from counting the number of captured frames inside the example Capture struct and checking if we should stop. So it can't be processing overhead. Can provide a reproduction repo (tho it's literally a <10 line change from the provided example - remove encoder, add captured frames counter, and do
captured / secondsat the end)