Show HN: Kickflip – Open Source Live Mobile Video Streaming SDKs • Hacker News Board

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

#31

Post by chrisballinger » Wed, May 14, 2014, 9:59 PM UTC

jgh wrote: post #19

lucasgonze wrote: post #17

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…

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…

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.

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

#32

Post by Mizza » Wed, May 14, 2014, 10:00 PM UTC

ldarcyftw wrote: post #22

Can you share your experience of the typical delay for CDNed live stream? 5 sec? 10 sec?

We found that Bambuser had a delay of around ~60s - ours is 10-20s, depending on the buffer size. It can be brought down to 5-10 by shortening the chunk size, but that increases the overhead somewhat. However, we're experimenting with this all the time, and optimizing based on the needs of our users, so hit us up via email if you have any specific requirements.

It is worth nothing that this is definitely a broadcast-first technology (at least for now), meaning that it's designed for delivering a high quality stream which will be seen by a large audience, rather than a low quality stream to an indivudual audience with a short amount of latency.

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

#33

Post by lucasgonze » Wed, May 14, 2014, 10:01 PM UTC

jgh wrote: post #19

lucasgonze wrote: post #17

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…

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…

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.

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

#34

Post by jgh » Wed, May 14, 2014, 10:04 PM UTC

chrisballinger wrote: post #29

jgh wrote: 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.

I've never actually seen this code before. I find it interesting that he found that the frames were arriving 500ms after capture, but I've used a similar technique (to how I did it in VideoCore) for video conferencing that achieved much, much lower latency than that. I wonder if that's something that was true in 2010 but is no longer true.

I also haven't really encountered much of an issue with frame reordering, but as it is I mostly don't care about that. I have noticed, however, that as of iOS 7.0.4 or so the encoder can output multiple slices per frame which it previously didn't do (or at least I never caught it doing it anyway)

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

#35

Post by haywardsmyfault » Wed, May 14, 2014, 10:09 PM UTC

lucasgonze wrote: post #28

haywardsmyfault wrote: post #21

Earlier quoted context omitted.

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.

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!

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

#36

Post by jgh » Wed, May 14, 2014, 10:14 PM UTC

lucasgonze wrote: post #33

jgh wrote: post #19

Earlier quoted context omitted.

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…

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

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.

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

#37

Post by jgh » Wed, May 14, 2014, 10:15 PM UTC

chrisballinger wrote: post #31

jgh wrote: post #19

Earlier quoted context omitted.

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…

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.

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

#38

Post by Akkuma » Wed, May 14, 2014, 10:49 PM UTC

Is the SDK going to allow a way to bypass all of the Kickflip infrastructure to allow the core streaming library to be used on your own maintained infrastructure?

On the product I work on, we already have our own house built media server and rtmp restreamer. As to not supporting RTMP, in our experience RTMP had much lower latency, which resulted in us switching away from HLS wherever possible.

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

#39

Post by Mizza » Wed, May 14, 2014, 10:55 PM UTC

lucasgonze wrote: post #18

Mizza wrote: post #16

Earlier quoted context omitted.

The CPU usage actually isn't a whole bunch, since we do the video stuff with the hardware encoders on the devices. It does use more bandwidth, since the streams are higher quality than other methods, but that's . It's also configurable.. it doesn't _have_ to be higher quality. Implementers can choose to lower the resolution. All in all, this is definitely a better solution for developers and clients.

This is definitely a cheaper solution than outsourcing to a cloud transcoding service, which is $$$. The streams are not higher quality than other methods. Your 720P is the same as everybody elses.

But everybody else doesn't have 720p, precisely because cloud transcoding is so expensive. By default, Bambuser broadcasts at a measly 240 resolution with a low bitrate, and other streaming services were similar. In our test, our video quality was always much much higher.

This is a great opportunity for a future blog post in which we explore the differences you're bringing up!

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

#40

Post by chrisballinger » Wed, May 14, 2014, 11:03 PM UTC

jgh wrote: post #34

chrisballinger wrote: post #29

Earlier quoted context omitted.

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.

I've never actually seen this code before. I find it interesting that he found that the frames were arriving 500ms after capture, but I've used a similar technique (to how I did it in VideoCore) for video conferencing that achieved much, much lower latency than that. I wonder if that's something that was true in 2010 but is no longer true. I also haven't really encountered much of an issue with frame reordering, but…

Yeah I made modifications to disable frame reordering and handle the extra SEI information properly, but I'll study your solution too because it seems really awesome. The lower the latency the better :)