In speaking to the original question about prerecording, the buffer is written to the sd card so on event the logic would be quite different. They would need to read from the card and transmit that data. The question for dev is do you just move your logic to reading from the card? Answer is no as that opens many avenues for failure as well as significant increases in viewing latency.
As to the statement regarding sd cards. SD cards are inherently slow and not high quality flash. What we need from dev is information on the number of write errors occurring. That tells us about bad blocks so we can initiate a reformat to have bad blocks identified and eliminated from writing. The hardware block size is important. An if you write a partial block, at the driver level the data is copied from the card, then erased and finally your changes written. Data should be written as N blocks for fastest performance. I forget the kernel param that controls buffering for you.
Security, my passion
Now on security, I have an excellent history and would be happy to have an offline conversation about the total end-to-end stream from camera to cloud and cloud to device to point out areas that I would attack. For internet connected cams we’d need to look at thr XBurst to see if they have addressed side channel attacks. I haven’t noticed any *nix patches specifically for this chip. Since I’m a user of these cams I’d happily work directly with devs for free instead of my $325/hr rate.
Thank you guys for individually salting the passwords.
Email me directly if interested.