Conversation
| if denominator != 1 { | ||
| numerator = 0; | ||
| } | ||
| numerator |
There was a problem hiding this comment.
As fare as I understand the API https://learn.microsoft.com/en-us/windows/win32/medfound/mf-mt-frame-rate-attribute the numerator should be divided by the denominator to get the frame rate.
| if denominator != 1 { | |
| numerator = 0; | |
| } | |
| numerator | |
| if denominator != 0 { | |
| numerator / denominator | |
| } else { | |
| 0 | |
| } |
There was a problem hiding this comment.
Yes, but as you can see here https://github.com/Giotino/nokhwa/blob/senpai/nokhwa-bindings-windows/src/lib.rs#L599-L636 Nokhwa doesn't support non integer framerates and simply reports 0 when there is one.
And, since the framerate is an integer, it's gonna report a wrong number if we use your approach, which is not to be ignored, but we should agree that framerate is not really supported by the device.
This was also written in my original issue (#144 (comment)):
Also nokhwa should keep in mind that there might be some framerates that are not X/1 (like 2997/1000), I think here we have 2 solutions that doesn't require to rewrite the frame_rate handling:
- Return an error when the framerate is not X/1
- "Transform" A/B -> X/1 rounding X (es. 2997/1000 -> 30/1)
There was a problem hiding this comment.
I think a rounded framerate is better than no frame rate
There was a problem hiding this comment.
Another argument in favor of rounding them are common rates such as NTSC's 24000/1001(=23.976...), for ease of use often referred to as 24fps. The same goes for e.g. 59.94, the aforementioned 29.97, and any VFR source reporting the average over the last N seconds
There was a problem hiding this comment.
0.11 supports non-integer frame rates as the new FrameRate struct is a rational fraction
4 participants
#144