Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

kickflip.io

Post reply on HN
Print view View original

11–20 of 51 posts

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

#11

Post by yarri »

Mizza wrote: post #7
elwell wrote: post #5

Besides using FFmpeg, are any novel optimizations/compression being offered?

We actually don't use FFMpeg to do the compression, we use the hardware encoders, so it uses much less CPU. That's how we're able to broadcast at a much better resolution. It's also bandwidth adaptive streaming, backed by a global CDN, and generates both Live and VOD HLS streams. But, more importantly, we've designed it in such a way that as a developer, you don't even have to worry about that! The library just expos…

Nice work! What are the min hardware requirements for iOS & Android devices?

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

#12

Post by Mizza »

yarri wrote: post #11
Mizza wrote: post #7

Earlier quoted context omitted.

We actually don't use FFMpeg to do the compression, we use the hardware encoders, so it uses much less CPU. That's how we're able to broadcast at a much better resolution. It's also bandwidth adaptive streaming, backed by a global CDN, and generates both Live and VOD HLS streams. But, more importantly, we've designed it in such a way that as a developer, you don't even have to worry about that! The library just expos…

Nice work! What are the min hardware requirements for iOS & Android devices?

Thanks!

Kickflip currently requires iOS 7 and works on any iOS device which supports iOS 7.

The Android requirements are a bit steeper, unfortunately: Android needs at least 4.3, as that's when the hardware encoder access API which we use was introduced.

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

#13

Post by [deleted] »

yarri wrote: post #11
Mizza wrote: post #7

Earlier quoted context omitted.

We actually don't use FFMpeg to do the compression, we use the hardware encoders, so it uses much less CPU. That's how we're able to broadcast at a much better resolution. It's also bandwidth adaptive streaming, backed by a global CDN, and generates both Live and VOD HLS streams. But, more importantly, we've designed it in such a way that as a developer, you don't even have to worry about that! The library just expos…

Nice work! What are the min hardware requirements for iOS & Android devices?

[deleted]

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

#14

Post by lucasgonze »

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 expensive - but from a customer satisfaction POV it's not an easy project.

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

#15

Post by jgh »

lucasgonze wrote: post #14

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…

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.

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

#16

Post by Mizza »

lucasgonze wrote: post #14

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…

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.

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

#17

Post by lucasgonze »

jgh wrote: post #15
lucasgonze wrote: post #14

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…

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 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).

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

#18

Post by lucasgonze »

Mizza wrote: post #16
lucasgonze wrote: post #14

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…

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.

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

#19

Post by jgh »

lucasgonze wrote: post #17
jgh wrote: 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…

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.

Post reply on HN