v4l2object: Fixed framerate negotiation
We had a problem with negotiation of the framerate.
Gstreamer was querying the FRAMEINTERVALS based on the max frame size instead of the desired frame size.
This was resulting in non-negotiated errors when trying to run with a smaller frame size and fps higher than the max for the max image size.
Fx the max framerate for 1024x1024 RGB on CMOSIS4000 is 28.292 While for 1024x100 RGB it is 280.867
But Gstreamer would allow any framerates bigger than 28.292 no matter the frame size used...
I have fixed it by 1st changing the CAPS query to use the minimum frame size instead of maximum. This however has the downside of allowing gstreamer to negotiate framerates that are too high if the image size is bigger than the minimum. This is not a huge problem since our driver just CLAMPS the fps value to the max then.
However gstreamer was not being properly notified of this change, and would therefore report a wrong fps in the CAPS structure. Note that the fps would be correct inside the buffer info. Since gstreamer was reading the fps back after setting it. It was just not being "propagated" to the CAPS structure. I have also added a WARNING to this point so we can see if the fps that gstreamer tries to apply was accepted or not.
And the next part of the fix was to add a framerate check after the frame size has been established. I did this inside the fixate_caps function of the v4l2src, which was calling the TRY_FMT in order to check if the format was correct. So I just added a check for the ENUM_FRAMEINTERVALS in there.
And now we get the non-negotiated again if the fps is too high for the selected frame size. Also added a couple of warnings so it is easy to see that this was the cause.
See: #3037 (closed)