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 single bitrate means HLS and RTMP - two encodes, two upstreams. (Only HLS means only Apple software - 20% of the mobile market, 5% of the desktop market).

Hello! Kickflip developer here!

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.

[1] http://en.wikipedia.org/wiki/OpenMAX

If you only offer a single stream, your claims of being better than cloud-based transcoders have no meaning. You don't transcode, they do.

You push a single stream, which any client can already do, and they can already live without transcodes. Your app doesn't add value by freeing them from the cost of cloud-based transcoders.

Our current offer is a significant cost reduction for a single high-quality broadcast to a large audience. On top of that we handle all the plumbing related to your iOS/Android cloud video app. Our SDK can manage all your application's broadcasts and users (if you choose).

I'm excited for our open-source Android and iOS clients to stimulate development of some novel video apps. Maybe Security monitoring systems or even Phone + $20 Weather balloon = Weather satellite!

Why should you have to encode twice for HLS and RTMP? The only reason to encode twice or more would be if you wish to have different movie properties (i.e. bitrate, fps, resolution, etc)

For example, for h.264, once you get the NAL units from the encoder (which in the case of iOS is a chip provided by PowerVR) you can encapsulate them in whatever format you need...mpeg-ts, MP4, RTMP, RTP, it doesn't matter...

I only support one simultaneous encode in my SDK, and I'm not actually sure how many the hardware would support as an upper limit.

I've done simultaneous hardware encoding before (two 640x480 videos) but I haven't pushed the boundaries yet. I have a hunch that newer phones might be able to do a few bitrates at the same time, but at that point we will do re-encoding server side because end users will have more limited upload bandwidth than our servers.

Interesting... I should do an experiment to see how many encodes I can do at once and what ends up happening.

jgh, it's a completely different stack for HLS publishing vs. Flash. Different media, different upstreams, different endpoints. Looks at any encoding/pushing tools.

It's possible to perform a single encode per bitrate, then split it between Flash and HLS on the server side, but then again that already exists in the form of cloud-based transcoders.

It's also possible to take that single encode - h.264, for example - and wrap it twice, once for MP4 and once for HLS, but that would be software, which is CPU intensive. If it's in software, it's not in hardware.

You don't need to do that though. The container or packet format is completely independent from the encoder format and they're all fairly simple, so packetizing compressed audio and video data and sending multiple streams, while not ideal due to bandwidth concerns, is most definitely not limited by CPU resources.