Please stop spamming the bluerobotics engineers, particularly without providing any additional information about what you’ve tried/what specifically you’re struggling with - they’re busy people and will get to your question when they have time.
Your framerate measuring logic seems fine to me, although it’s better to use time.perf_counter() than time.time() for precise timing scenarios. The actual issue you’re having is that the Video class defined in the ardusub docs will always have frame_available after the first frame has been read. If you check how it’s defined it just checks that the internal _frame variable isn’t None, and the Video.frame function just returns what’s currently stored in the _frame variable. Accordingly, there’s no way (without modifying that class) to find out the actual rate that frames are coming in - what you’re timing with your current code is just how long it took to get to the next loop iteration, which should be a couple of milliseconds.
If it’s important for you to know the actual framerate you can modify the Video.callback() function to do your timing for you instead (since that’s when each new frame actually gets pulled in), or you can change to using gstreamer as an opencv backend instead of as a python library, and use something like the measure_framerate function in my library pythonic-cv, as I’ve outlined here.