Earlier quoted context omitted.
Encoding is done in hardware on the client side and doesn't increase CPU load by very much. I'm using the same trick in a library I made to do game broadcasting from iOS and honestly network traffic increases CPU load more than encoding an 1136x640 video does.
Can you be more specific by "in hardware"? I'll buy that there's some trick analogous to shaders on the desktop. But I'd want to know the specifics to be able to evaluate that. How many encodes have you been able to do, anyway? Encoding and upstreaming a single 640p video does seem plausible. But for each additional encode you need HLS and RTMP, and both CPU and upstream bandwidth grow linearly with each encode. A si…
The SoCs included with virtually every mobile device today have circuits designed specifically for encoding/decoding H.264 video and AAC audio. This is how your mobile device's native camera app reliably records HD video. Whether it's 640p or 1080p, there isn't a significant drain on system resources.
These chips were traditionally accessed via a standard OMX[1] library (Think OpenGL for Video hardware), but the OMX implementations were device specific, making it nearly impossible to write custom video software with mass market appeal.
Just recently (July '13 on Android), the video hardware has become somewhat controllable by the standard Android / iOS platform APIs allowing us to write a truly compatible video product.
We currently only offer single stream output. When we do offer multiple bitrate outputs (transcoding), we'll do that work serverside.