1. Classify whether you need low MIPS or low complexity overall
Let me take a small liberty to split this problem in two parts.
- Low complexity encoding - which allows lower resources (specially in memory) to make it quick responding encoding in the given system.
- Low explicit in computation (MIPS). - which only concerned with minimum possible CPU cycles.
There is third criteria - where in people talk about "Low latency" - for application like Video conferencing where computational resource might not be of concern -but overall delay introduced by coded
What is important to note that in lower complexity systems - access to memory (memory bus speed and width) and sometimes IO are generally extremely slower which is why MPEG class of algorithms suffer even though the computationally algorithm could be simple.
Before you make judgement about the requirement for codec - you should try to make budget in terms of -
a. CPU cycles per second.
b. Maximum memory through put.
c. IO latency
2. You should customize MPEG rather than re-invent
In general - MPEG class of codecs gives you a very flexible mechanisms to do this. In that sense, you don't quite have to re-invent the codec as much as you would rather customize MPEG 2 or MPEG 4 to get your work done.
First off, let's say what all elements make compression possible and arrange them in the order of complexity:
- Motion Estimation and Motion Compensation.
1.a. Forward prediction (P frames)
1.b. Double prediction (B frames)
1.c. high resolution motion vectors
- Intra coding - DCT (+ IDCT)
- Qunatization - and encoder mode selection
- VLC - variable length coding. (CABAC in H.264)
- Co-efficient prediction [ In mpeg2 only DC prediction- MPEG4 has more]
In MPEG class of algorithms, the DCT based encoding and VLC becomes pretty much compulsory without much choice - but rest of all mechanisms are very essential
For example, Motion estimation and motion compensation is one of the highest MIPS consuming element. If you don't have resources to do this - you can simply encode all frames as I frames (which makes it pretty much like MJPEG - but standard MPEG decoder can decode this). If you can afford slightly more resources - you can make trivial motion compensation using Frame difference - instead of sending every frame as Intra, you can subtract every blcok from it's previous frame block; if the difference is higher than original signal send it as Intra.
Of course - all this would mean that you will loose some efficiency promised by above encoder - but i think you are willing to give up that!
You can look at the following codecs as good reference points:
Good for understanding but might be next to slowest in the world.
Probably the fastest on the earth. Good to start as black box but don't try to change the code from inside. Might give you good options to control stuff when you use library API. It is already ported in many platforms - but doing it on a new one might be some task.
This was originally started with purpose same you described. Though, i am a bit out of touch of this - but you can try this.
This is MPEG-4. This is one of the best balance between clean code and reasonable speed. Should be easiest to work with if you endup dwelling inside of the encoder.
This is JPEG. This is one of the best libraries to port it across platforms. Also, JPEG is inherently simpler than some aspects of MPEG - so may be you should try this first. Most camera's in the world has probably used this library as is - rather than creating something its own!
May be i am wrong in using MPEG! But that's a kind of risk worth taking.
Probably best measure to check if that will work or not is - just try to take a standard 8x8 DCT with quantization on your image; optimize just this. If you are able to reach close to your real time requirement, than i think you are good to do about all All JPEG frames or all I frame MPEG codec. If you are way off the target - than it is not worth it.