Live data from Hacker News

Show HN: Kickflip – Open Source Live Mobile Video Streaming SDKs

kickflip.io

21–30 of 51 posts

Re: Show HN: Kickflip – Open Source Live Mobile Video Streaming SDKs

#21
post #15

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…

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

Re: Show HN: Kickflip – Open Source Live Mobile Video Streaming SDKs

#23
post #2

Hey guys! Rich from Kickflip here. We've been working really hard on this for a long time and are super happy to get to announce it today. Kickflip is some really cool tech - we've lowered the cost of mobile video broadcasting by orders of magnitude, and we've opened it up to everybody! If you've got any questions or feedback, let me know and I'll be happy to answer them. Thanks very much!

Glad that someone is doing this. The last time I looked at it, it was hard to do hardware encoded video (out)streaming well on the iphone. The open API only allowed writing the compressed stream to a file. Pipelining or FIFO tricks did not work well because the file was not in a consistent state untill it had been closed. It appeared that the OS was not flushing key metadata until then. So the options seemed to be either have a quick cycle of starting and stopping recording on a ring buffer of files, this would drop frames; or parse and fix (with some second guessing) the compressed stream in the application. The first one was easier to implement but quality wasn't great, although software interpolation of the dropped frames might help some. The second seemed too much work.

Has the scenario on the open API changed ? I would guess not. Congrats for taking care of this.

Re: Show HN: Kickflip – Open Source Live Mobile Video Streaming SDKs

#25
post #9

Very cool! I've recently open sourced a good portion of my game broadcasting SDK, which now has a few people using it for purely making camera apps to stream to RTMP services. Mine is not nearly as refined as this one, nor do I have any sort of CDN heh. Congrats guys, looks awesome.

Hey https://github.com/jamesghurley/VideoCore looks great, wish I knew about it earlier.

Re: Show HN: Kickflip – Open Source Live Mobile Video Streaming SDKs

#26
post #23
post #2

Hey guys! Rich from Kickflip here. We've been working really hard on this for a long time and are super happy to get to announce it today. Kickflip is some really cool tech - we've lowered the cost of mobile video broadcasting by orders of magnitude, and we've opened it up to everybody! If you've got any questions or feedback, let me know and I'll be happy to answer them. Thanks very much!

Glad that someone is doing this. The last time I looked at it, it was hard to do hardware encoded video (out)streaming well on the iphone. The open API only allowed writing the compressed stream to a file. Pipelining or FIFO tricks did not work well because the file was not in a consistent state untill it had been closed. It appeared that the OS was not flushing key metadata until then. So the options seemed to be ei…

Unfortunately Apple still doesn't expose the APIs that we need and are forced to use tricks to get the encoded frames. We based our hardware encoder wrapper on the technique described by Geraint Davies [1], but have modified and improved upon his method.

The main trick is to encode only video frames in your temporary .mp4 file, and to make an additional 1 frame .mp4 file for extracting the avcC record.

1. http://www.gdcl.co.uk/2013/02/20/iOS-Video-Encoding.html

Re: Show HN: Kickflip – Open Source Live Mobile Video Streaming SDKs

#27
post #25
post #9

Very cool! I've recently open sourced a good portion of my game broadcasting SDK, which now has a few people using it for purely making camera apps to stream to RTMP services. Mine is not nearly as refined as this one, nor do I have any sort of CDN heh. Congrats guys, looks awesome.

Hey https://github.com/jamesghurley/VideoCore looks great, wish I knew about it earlier.

Thanks! It's a side-project but I try to fix any bugs as quickly as I can and I've got some new features planned/in development for the future.

Re: Show HN: Kickflip – Open Source Live Mobile Video Streaming SDKs

#28

Earlier quoted context omitted.

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…

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 f…

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.

Re: Show HN: Kickflip – Open Source Live Mobile Video Streaming SDKs

#29
post #9

Very cool! I've recently open sourced a good portion of my game broadcasting SDK, which now has a few people using it for purely making camera apps to stream to RTMP services. Mine is not nearly as refined as this one, nor do I have any sort of CDN heh. Congrats guys, looks awesome.

Wow, if only I knew about VideoCore earlier! I used a modified version of Geraint Davies temp .mp4 file hack, but it looks like you developed a great alternative.

Re: Show HN: Kickflip – Open Source Live Mobile Video Streaming SDKs

#30

Transcoding on the client instead of in the cloud increases the amount of CPU and upstream bandwidth needed, and both are in short supply on phones. To put this in perspective, three live encodes/ streams (360P, 540P, 720P) using Wirecast on a high end Macbook Pro pegs the CPU around 60% and requires at least 5MBPS upstream. I understand the financial reasons for this architecture - cloud-based transcoders are crazy…

Hey HN can we stop this petty downvoting please. It is starting to get really annoying. Dont know if anyone else has noticed this, but it seems stories these days are riddled with greyed out posts, even perfectly legit comments. I try to compensate with upvotes, but as I said this is really leaving a bad taste everytime I see this happening.

This change seems highly correlated with the change of hands. I thought this would be a temporary phase, but seems to have become worse with time. I think a line of over-moderation is being crossed here.

I would try and flag my own comment so that it gets some attention. EDIT: Unfortunately it seems one cannot do that, but if you agree, and can flag this, please do.

Post reply on HN