Contents
When working with moving machinery, high frame-rate video can be incredibly useful for all sort of real-world debugging scenarios. After purchasing a Motorola Edge 30 Fusion in early 2023 I was intrigued by the advertised 960fps video mode in the tech specs.
The main camera sensor, an OV50A, lists 480fps @ 720p as possible and there’s actually enough bandwidth to hint that maybe, just maybe, 960fps could have been achieved as a special capture mode.
Sadly, and perhaps unsurprisingly, it turns out that anything beyond 240fps results in interpolation. The following is a description on how actual frame-rate limits of the camera have been tested.
The slow-motion camera recording mode on the Edge 30 Fusion is pretty limited, giving almost no control over the recording behavior besides a 120, 240 and 960fps video choice. In 960fps mode the recording only lasts ~4 seconds before stopping automatically.
Ironically, this wouldn’t be out of line if the sensor was actually streaming faster than the phone’s encoding/saving capability, which normally results in a limited recording time window. As we’ll see later, this limitation has no hardware basis and is probably there just to limit the output file size.
Once the video is saved, instead of just embedding the correct frame-rate, the video is always set to 30fps and you are required to “expand” a section of the video where all the extra frames are actually inserted. For that dramatic slow-mo effect. In 240fps mode the “expanded” section can span the entire video, while in 960fps it is additionally limited to a shorter subsection. If the video is not “expanded”, the frames are simply dropped.
Having doubts in the 960fps recording capability I devised a simple test to check the rough limits of the video capability by blinking LEDs in front of the camera: if we turn on and off a LED slower than the recording rate of the camera, we should indeed see it blinking. If we turn it on and off faster, the blinking should disappear and start to dim instead.
Thus, by changing the speed at which the LED is blinking, we should be able to determine the effective recording rate of the camera.
At 960fps the frame interval is 1/960 seconds, or ~1 millisecond, or 1042 microseconds. Even in the worst-case scenario, phosphor-coated LEDs have a on/off time of ~1 microsecond, whereas a typical LED operates in the nanoseconds range, meaning that for our purposes we can consider the LED transition to be instantaneous (it’s at least 1000x faster). Driving anything on/off in the millisecond range is trivial for even the dumbest micro-controller so a typical Arduino with any random LED will do the trick.
To interpret the results, a very basic introduction to how the camera sensor captures the image might be useful.
At 240 frames per second, each frame captures an instant which is 1/240th of a second long [1] where it behaves like an analog photograph. We can’t directly “see” what happens as the frame is being captured, we only get the accumulated light during this entire 4.7 millisecond period.
If we turn on a LED in front of the camera before the frame is being recorded, and we keep it on for the entire duration of the frame, the resulting intensity of the light will be the greatest.
It follows that if we turn off the LED exactly halfway while the frame is being captured, the intensity will be half of what we measured earlier. Assuming the brightness of the source (our LED in this case) doesn’t change, the resulting intensity is then proportional to how much time we keep it on during the sampling period (fig. 1).
To make a LED blink perfectly and at maximum brightness in a video at 240fps, we need to turn on the LED exactly when the frame starts being recorded, then turn it off exactly before the next frame starts after 1/240 of a second, wait another 1/240 frame period, then repeat the cycle.
By doing this the first frame would show maximum intensity while the second frame would show nothing, resulting in a perfect blinking pattern (fig. 2).
But unless we take special measures to synchronize both systems, we can’t actually know when the frame capture is started. Most likely, as we start the blinking cycle, the LED will turn on in a random point of the current frame, then turn off during the next. When the duration of the LED interval matches the duration of the frame, as in this case, the frames will alternate between two repeating states: one where the LED is on most of the time and one where the LED is off most of the time. The led thus still appears to blink, but doesn’t shine as bright and doesn’t seem to turn completely off (fig. 3).
If we get lucky, we might happen to cycle the LED exactly halfway through each frame. In this case the duration of the on/off phase of the LED would be the same in both frame states: half-on during the beginning for the first frame, and half-on during the end for the second. Since the accumulated light is identical in both cases, the led doesn’t appear to blink in this condition (fig. 4).
Besides not being able to synchronize the start (the phase) of each cycle, two distinct systems having separate clocks will almost never tick at exactly the same frequency either.
One of the two systems (the camera or the LEDs) will be slightly faster or slower, causing the phase to move slowly but continuously at each frame.
In this scenario the LED will drift across all the two-phase state possibilities, resulting in a smooth cycling fading effect (fig. 5).
When the two system’s intervals are close, but not exactly the same, each of these three major (blinking, steady, fading) modes will keep on alternating. The closer the intervals are to each other, the longer each pattern will last.
When the LED has an interval double or greater compared to the frame duration, it will always blink, because there is always one entire frame every 2nd where the LED is cyclically completely on and then off. Fading can still be visible on two of the remaining frames of the cycle, due to the phase alignment.
Finally, when the LED has an interval which is half or smaller, the blinking stops instead. This happens because, for every frame, the LED always completes an entire on-off cycle. The total amount of delivered light stops changing irregardless of the rolling phase, making the LED appear steadily half-bright.
[1] | This is not strictly true, since with a strong-enough illumination the actual exposure time of an individual frame can be shorter while keeping the frame interval the same. For smartphone-sized sensors light is rarely sufficient though, so this detail can be omitted to simplify the description. |
To test the actual recording capability we can blink a LED where the on (and off) interval matches the frame rates we want to test. By looking at the resulting blinking pattern we can individually test if the recording is slower, as fast, or faster compared to the pattern itself.
To test 240fps we first keep the LED on for 1/240 of a second, then off for 1/240s and then repeat indefinitely (the LED is thus blinking at 120Hz). To test 480fps we use a 1/480s interval (240Hz), and for 960fps a 1/960s interval (480Hz).
Instead of repeating the experiment three times we just blink three LEDs with multiple frequencies at the same time, giving us the limit we need in one observation: one lower than the expected, one at the limit, and one faster.
In the following videos the arranged LEDs have an interval of 1/120 (red), 1/240 (green) and 1/480s (blue) respectively. The video has been captured at “960” fps, the fastest available:
We always see the red LED consistently blinking, meaning we’re recording as fast or faster than 120fps. The green LED is slowly cycling from steady/blinking/fading patterns, meaning we’re close to the recording limit, which is 240fps in this case. The blue led appears steady, so it must be blinking faster than what we can record. Obviusly, if the camera was truly recording at 960fps, all three LEDs should have been blinking.
So much for the OV50A 480fps recording mode… I guess once you need to implement interpolation why mess with the real deal? Just crank 240fps to 4x and call it a day.
For completeness, I then repeated the recording with the full range of 1/240 (red), 1/480 (green) and 1/960s (blue) respectively:
The red LED is now cycling through the various patterns, meaning we’re close to the 240fps recording limit. The green looks steady, but is less (half) bright compared to the maximum brightness we could see before. The blue LED is unchanged, as in both videos it’s blinking faster than the recorded frame rate.
The pen is just used in the videos to keep the camera focused at the right distance.
You might think that interpolated video can still be useful, but let’s not forget interpolation is just another fancy word for guessing. Slow-motion interpolation usually doesn’t just fade pixels in-place from frame-to-frame, but attempts to perform motion interpolation as well in order to keep the additional frames realistic.
By chance, when blinking two LEDs at very close frequencies, I was able to get a visible artifact lasting exactly 4 frames which is shown enhanced here: the motion detection thinks that one of the LEDs is moving from left to right instead of just fading it in-place, helped by the fact that both LEDs are identical and the rest of the scene is mostly dark with little or no detail to latch on.
The visible banding in the interpolation is originally horizontal (the video has been recorded vertically then rotated). You can see the full video here where it happens multiple times:
Both at the time of purchase and half a year later (2023-10-15 at the time of writing) the Motorola Edge 30 Fusion (archived) page still shows “960fps HD recording” in the technical specs, without any mention of interpolation.
This is akin to the old scummy behavior of advertising early digital cameras with a fixed lens as 4x zoom, without pointing out that the zooming is purely digital (aka: worthless). This behavior is less common nowadays, with optical zoom generally being considered the “only” zoom worth mentioning, or at least with “digital zoom” being labeled as such.
It seems that fake/interpolated high-framerate video, in it’s numerous consumer forms (“ultra slow-mo” & friends), is just the current target of marketing lies and needs to receive the same treatment. I feel absolutely no shame in pointing fingers to Motorola/Lenovo for deceiving advertising in the official “technical specifications”, especially when the Lenovo support team itself answers in a forum post that the feature is just interpolation.
I attempted to contact official’s Motorola’s press through e-mail on this matter on 2023-09-27, which immediately bounced as no longer existing despite being the only contact shown alongside “support forums”. I subsequently tried again on the same day through Lenovo’s press contact for an official statement. I did not receive a reply.
It’s also worth nothing that Motorola/Lenovo is far from being the only company deceiving the consumers on this specific feature. The problem is widespread on almost all consumer-grade cameras, smartphones and other devices, but this is not an excuse.