The tests have been made with lower resolution than in the live system we need, so decreasing is not an option. But it does not matter, as I see it is not a performance overhead problem, as based on the earlier mentioned tests:
it appears only if we get the pose of CV frames.
If we did not query the CV frame pos, than we can write any amount of data to the disk with much larger bandwidth too and we can record until the disk capacity or batery allows. (the FPS is not stable but the app works without crashing)
it does not matter what is the bandwidth the writing process is using, the program crashed after writing a certain amount of data. ~34GB
If we decrease the amount of data written per sec, then it does not help, as after writing the same amount of data the system crashes. (e.g. writing out only each 100th frame; for this we did not modify our code just used a modified FileStream class)
Moreover, if after a crash we restart the app and the device, but do not delete the files, just move them to another place, the crashes will appear after writing 2-3 GB! Even if we have ~150-200GB free disk space.
So, this situation seems to be similar to the case when "The Ford did not start when the driver bought vanilla ice cream"
Unfortunately, in the current phase we cannot record remotely on the places where the recordings have to be done
@kocsisa I wanted to report that the new SDK includes several improvements to the camera API that should make your app work better. Additionally, there was a fix on the Core SDK level that should resolve the issue. This process should no longer kill the application.
Although the device will stop rendering for a period of time when it runs out of resources, the graphics will recover properly. I recommend trying out the latest OS version 1.5.0 .
I have marked the topic as solved, but if you feel like the error still persists let me know.
We tested with the new OS version and SDK.
Now CVCamera getting pose does not lead to app crashes.
The capturing FPS is not stable.
I attached an image which shows a capturing FPS rate chart.
we captured center world camera, the depth Image buffer and the CV camera on full HD with 15 FPS but we limited saving/sending images to 10 FPS
The first 6 minutes is stable, but after that there are drops event to 0 FPS. The interesting thing is that at the end it was more stable than in the middle.
