I see! Yeah the main problem is computing power. Also memory (assuming interframe would require storing several uncompressed frames in memory).
It can be huge. (I've seen an easy %50 for a recorded graduation ceremony.) It can also be none. The idea is, if you can afford it you absolutely should use an interframe compression algorithm. Even if nothing is shared between target frames the overhead of the interframe compressed stream is generally negligible compared to the same data using simpler intraframe algorithms.
Thanks for the offer, but I would really want to keep this public. Also, after doing some more research, I don't think it's really necessary to do my own encoding.
Yes. I may be willing to discuss this with you a little more to get you started, but I don't know where in the world you exist. It would have to be private communication.
That's true. I really want something lossy.
That's actually a really bad idea.
The human eye just isn't that great. A dumb scheme for binary comparison and delta recording is guaranteed to manage a lot of redundant data when you realize that we can't tell the difference between subtle variations of color and intensity.
Yeah I don't think the ARM can do it. ~100MHz is about as fast as they go. Anything faster (eg. Cortex-A8) would be a lot more complicated because it would just be a naked processor, and require a bunch of supporting circuitry, instead of a nicely packaged microcontroller that includes RAM, flash, and peripheral.
Your ARM CPU seems typical of current crop of non smartphone handsets. Of those that are capable of video telephony, the performance is down at level 1 for a small display.
You may need that DSP if you want the image size and frame rate. The bit-rate won't be an issue for your interface if you can hack the math in the CPU(s)
I chose SPI just so the bus bandwidth won't be the limiting factor. But storage requirement and wireless streaming bit rate still are. The data has to go somewhere eventually.
Motion JPEG - Wikipedia, the free encyclopedia
Like it says, less CPU, but less compression. But probably still within the bandwidth of your SPI interface.
It should be relatively easy to benchmark this approach to see if it's worth pursuing.
With 40Mbps I can probably even do uncompressed stream.
Benchmarking is a good idea. I didn't want to do it because I'll have to build the hardware first. But I guess I can do it on a PC, and assume it will scale relatively linearly.