We extracted the video frame by frame as images and processed them, with each image being 1-3Kb. And used the drawImageFromFile command to print them on the screen. We found that the frame rate decreased as the printing time increased, which also affected the running speed of other threads. Later, we tried to read the file into memory first and then print it, but the situation was the same. I don’t know what method can be used to solve this problem.
Does this mean you have hundreds, perhaps thousands, of images on the SD Card ?
The issue is that opening the file will take longer if the firmware has to search through many directory entries. So yes, the apparent time to open an image may take longer.
Have a small number of files on the SD Card. It’s better to have one large file that you access for data and keep that large file open. That’s how I did the video playback in this post.
5 Likes
I tried to reduce the number of images and limit the playback frame rate today, but it still affects the operation of other threads.
The total number of images is now about 600, and playing for about two minutes will slow down the overall program speed (including other threads).
Every time it refreshes, it will freeze for a moment, which is quite fatal when manually controlled, causing significant delays. However, it is indeed much better than not limiting it.
We have assigned a buffer pointer to the program now. I am not very clear about how the firmware internally plans to use it.
Does it overwrite an image that has already been used each time, or does it accumulate a large number of images in the cache?
If there is no automatic overwrite, is there a way to clear the occupied cache?