As per the description, it looks like the video is streaming fine at 640x 480 @ 30fps. But the software packages using by the customer couldn't handle the bandiwdth of 640 x 480 @ 30fps. Hence, you want to reduce the resolution (320 x 240) by keeping the same frame rate (30 fps).
As per the OV5640 datasheet, the least resolution supported is 320 x 240 @ 120 fps.
All the supported resolutions are as follows:
maximum image transfer rate:
QSXGA (2592x1944): 15 fps
1080p: 30 fps 1280x960: 45 fps
720p: 60 fps
VGA (640x480): 90 fps
QVGA (320x240): 120 fps
If you wanna go with 320x240 @ 30 fps, change the UVC descriptors and probe control structure associated with USB 2.0 descriptor:
1. /* Class specific Uncompressed VS format descriptor */
2. /* Class specific Uncompressed VS Frame descriptor */
You need to configure the MIPI as per 320 x 240 @ 30 fps resolution.
Also need to change GPIF data bus width, if needed.
I was able to correct the error in the demo software which calculated bit rate to 60 fps although it was set for 30 fps. That actually did cut the data rate in half without any effects to the picture. We should feed this back to E-con. This was mentioned in my last paragraph above and the screen shots showed the error.
Unfortunately, that improved performance and did cut the data rate in half, but it is still freezing too much. I have tried 2 more changes and they will be tested by my customer tomorrow. I lowered the set bit rate in half again. I got those parameters by setting the frame rate in the software generator tool to 15 fps. I made an image with the data rate lowered ONLY (no other changes) which is the same successful things done this weekend. The difference is that the previous was an error where the bit rate was double what was needed. This time, by calculation, I will be half what is needed. The code worked, but the test will be tomorrow for the achieved output data rate.
I then made additional software changes to actually reduce the fps to 15. I did find something that I do not understand in the result. On the E-con viewing software the fps in real time under the video is 30 fps and sometimes a frame or 2 lower for a second. This indicates it did not work, but when I pull up the screen to change resolution (only 1 available in 2.0 mode, but the same screen) it shows the 15 fps I set the code to. Did I miss a spot to truly get to 15 fps? Did I really achieve 15 fps since it reads 30 below the video? I changed something since the control screen changed.
Is there a way to reduce the quality of the picture other than resolution and frame rate? The cheap Chinese camera is definitely less quality, but is 640x480 @ 30 fps. I have found online that bit rate defines quality and is a different variable, but cannot see how to apply here (unless what I did tonight actually works).
You can set the sensor to stream in different pixel data format.
For example, Instead RGB24 format, use RGB10 or RGB8 will reduce the frame size.
For this, you need to check with the sensor manufacturer.
I hope that this may help you.
Thanks for the responses, but it is not exactly what I was looking for, although it may have worked.
I wanted to lower the bit rate for the same resolution. Now maybe a different format is the way to go, but that was not pursued.
As stated, I did correct an error in the software that was actually doubling the bit rate WITHOUT providing extra frame rate or resolution. That helped, but was not enough for the software. I did also try lowering it more without changing resolution and that did not work as it defaulted to the correct minimum.
I was able to lower the frame rate to 15 fps, but that that turned out not to be desirable and one of the 3 software packages still had issues. At this point, it was obvious the software packages were the real issue so the customer is now working on licensing a 3rd party twain which will capture even the 720p USB 3.0 video streams which the camera is capable of. That is the best option, but he was trying not to introduce a 3rd party software for multiple reasons including something else to go wrong on the installations.
I appreciate all the help. Ultimately, we did learn of a software issue in the RDK software and how to correct it along with a solution since the software was not good enough.
Thank you so much for the update. This will definitely help others who come across similar situation.