🚀 Live streaming with Cloudflare Stream
Presented by: Apoorva Ravikrishnan, Zaid Farooqui, Mickie Betz, Renan Dincer, Kyle Boutette
Originally aired on July 31 @ 12:30 PM - 1:00 PM EDT
Cloudflare Stream now supports end-to-end live streaming. Learn how you can use Stream to build live functionality into your apps.
Read the blog post:
Find all of our Birthday Week announcements and CFTV segments at the Birthday Week hub
English
Birthday Week
Transcript (Beta)
Hi everyone. Thanks so much for tuning in. Today is the fourth day of Cloudflare birthday week and we are celebrating our 11th birthday by announcing a series of releases that are designed to help build a better Internet.
I'm Apoorva Ravikrishnan from the product marketing team and I'm here today with folks from the product and engineering team to talk about StreamLive, Cloudflare's serverless end-to-end live streaming platform.
Before I pass it on to my colleagues here so they can introduce themselves, I want to note that if you have any questions whilst you're watching the segment, please do send them in.
We'll be saving some time to at the end to respond to them.
Anyway, Zaid, do you want to do a quick introduction? Yeah, so my name is Zaid.
I'm the product manager on Stream. I've been at Cloudflare for about a little over three years and the whole time I've been working alongside Renan and the rest of the team on the Stream product.
Really excited to finally take on live.
We've really done well with on -demand the last few years and this was just the natural next step.
Thank you, Zaid. Renan? Sure. So my name is Renan. I manage the video, the Stream team at Cloudflare.
What else do I say? I've been at Cloudflare for five years and I agree with Zaid, long time coming.
We've been working very hard on this and it's very exciting.
Thank you. We're all excited too.
Miki? Hi, I'm Miki. I'm a software engineer on Stream. I've been on the Stream team for three years.
Yeah, I guess echoing what everyone said, this is like a long requested feature slash product.
So very excited to be launching it today. Thank you.
Kyle? Yeah, I'm an engineer on the Stream team. I've been here for about three years and the entire time working on video.
It's fun to work on and I'm glad we're finally being able to ship live.
Thank you so much. We are excited for this segment to hear all about Stream.
I think it'd be great if we could talk about an overview or history of Stream and what we've been doing so far.
So Ken, can you give me an overview of Cloudflare Stream?
Yeah, so I can tell a little bit about Cloudflare Stream, the journey that we've been on.
So Stream launched, went into GA about three years ago.
And at the time that we launched, we only did a video on demand.
But let's rewind even before that. Why does Stream exist? So Cloudflare, we don't build products because we think everyone else is building it.
We build products when we think we have an opportunity to uniquely help the customers that are on the Cloudflare platform.
So about three years ago, we saw a lot of demand for customers wanting to do more with video, using the Cloudflare network.
And often, when people think about Cloudflare, they were thinking that, oh, we can see you have this network and you can help us deliver the last mile to our end users using this network.
But here's the thing about video, that just scratches the surface.
Just helping you deliver bytes to your end users is scratching the surface, especially with video, because when it comes to video, there are so many factors that can impact the end user experience beyond the user getting the bytes on their client device, on their computer or their phones.
So what are those things?
So those things include how you encode the video, the protocols you use to package the video.
If the video is tiny, you might want to just deliver a straight MP4 file.
If the video is long, if the video is high definition, there are different decisions that you may need to make.
We saw a trend that customer after customer that we talked with were having to go through the same challenges and were having to answer the same questions.
And whenever we see that, for us, that's a big opportunity.
Cloudflare customers love us because we look at common problems that a cohort of customers are wrestling, and we zoom out and we think about what can we do different that can help a wide variety of our customers.
And we're very interested in the position because we have customers of all sizes, customers that haven't actually haven't paid us a dime, and yet we're very happy to serve them.
And customers that receive tens or hundreds of millions of users in their app or on their website.
So for us, it's really interesting when we can zoom out and think of solutions that can cater to not just large companies, but companies of all sizes, companies that are just dreams that someone is building over the weekend, as well as companies that are mature and are looking to move away from their legacy infrastructure and thinking about the next five to 10 years.
So Stream started three years ago as an all-in-one solution where you upload a video to Cloudflare, we store the video, we encode the video, and we make it really easy for you to deliver it to your end user using the Cloudflare Edge and all the video technology that comes out of the box with Cloudflare Stream.
It really sucks that when you're building something and you know that so many people built the same thing over and over and over again, and some of them are two years old, some of them are 10 years old, it's the same solution, and everybody's done video streaming for a long time.
It's not new, like video on the Internet, but people keep building the same thing over again, and in the end, people don't focus on what they want to focus on.
If you're an e -commerce person, or if you're streaming movies, it's kind of the same solution underneath.
Thank you for giving us a history of that. Looks like a lot of technology has developed, and then I love the fact that we do this, as I put it very beautifully, that we do this not just for paying audience, but also for folks who really want to just build this out.
Anyway, thank you for taking me through that.
I was wondering if we could talk about something that we particularly launched today, Stream Live.
Maybe I can talk about that. So, today we launched Stream Live.
So, Stream has been, for years now, doing video on demand, so recorded content.
Previously, you were able to upload videos that you previously recorded, or you made to Stream, and then Stream would make it available for you to view it on your website, or on your app, or where have you, at scale, and in multiple quality levels, and with all the features that you'd expect, like closed captioning, et cetera.
Today, we are introducing the ability to live stream, in addition to having recorded content, having live streams on Cloudflare Stream.
What this means is you get all the benefits and all the features that you would get with having recorded content, but you can now deliver it as it's happening to customers, again, at scale, with features that you'd expect on video streaming platforms, with features like access control, and features like watermarking, and all these different things.
And when the live stream ends, it automatically goes into a recording, just like any other recording that you might have uploaded to Cloudflare before.
And this allows an entirely new set of use cases, in addition to improving previous use cases that people have been using Stream for.
And yeah, it's very exciting. And you can push video from entirely new devices, and new places, and from concerts, and places that the video is most valuable when it's first produced, and make it into, for example, content.
Conference TV is a great example of this, that people can go back and watch.
You know, probably most of the viewers of this just watch it right now and forget about it.
But it's automatically available in the recording section, right? So this is what we launched.
That's very exciting. Thank you for mentioning that. And what are the key benefits for developers with Stream Live?
And who is going to be our ideal customer for this?
Yeah, so the biggest benefit for developers is something that Ranaan touched on.
Our developers, or our customers, want to focus on what makes them and their ideas special.
What makes the idea special is not necessarily, you know, like doing video encoding, or being able to store videos, right?
At the same time, those things are not easy or simple, right? To build a very hacky V1 might be simple, but to actually build a scalable video pipeline that takes into account storage, encoding, new encoding standards that become popular, you know, say a year or a few years from now.
That takes a lot of effort.
And conversation after conversation with our customers, we saw a strong urgency from our customers to ask Cloudflare, can you help us with this, as you've helped us with many other challenges and products, so we don't have to reinvent the wheel for problems that are well understood, and yet are incredibly challenging.
So I think that's where Stream really shines for developers. For us, we think about it in terms of your use cases.
You have users, customers, who want to upload videos, who want to go live from your app, right?
The API, the product is really built from that perspective, so you don't have to learn granular video terminology, and you can focus on the end -user experience.
The end-user experience is, can our users go live from the app?
The end-user experience is, can the global audience that we have, can they watch video with all types of different constraints around devices, network speed, things of that nature?
Those are the answers that you no longer have to worry about when you use Stream, because we come into work each day helping answer those questions and improving the answers to those questions through our product.
So it sounds like it was truly built by developers for developers, right?
So that's incredible. I mean, absolutely. When we actually have important product questions, I often put the ball in Mickey's court or Kyle's court, and I say, well, if you were building this from scratch, or if you were evaluating APIs, not being on the Stream team, what would you wish the API would do?
What would you wish the product would do? So I think it's something we work incredibly hard never to lose sight of, and we're lucky that we have team members that we can count on to provide a very useful perspective.
Thank you.
I think that's a good segue to find out some of the technical challenges you might've encountered while building and developing Stream Live.
Yeah. So working on Stream is always fun because you get to solve problems that people always encounter when they try to build a video solution, but you get to solve it for all of your customers instead of each customer trying to solve it independently for their exact use case, which wastes a lot of time and it results in a lot of unnecessary complexity.
So for Live specifically, one of the hardest things is reliability because you need to be reliable, right?
If you're watching somebody play a game and the stream drops for two seconds, that content's gone.
It's gone. You don't have that anymore.
And even if you show it to them the two seconds after, they don't want to see those two seconds that they missed.
They want to see what's happening now.
So to hit a highly reliable state, we ended up iterating on our architecture as we built things out.
So we started with long-lived encoders that could fail over infrequently and we got it to a good place.
We were reasonably happy with it, but the complexity it introduced was pretty hefty.
At that point, we figured out that we had an alternative approach in our back pocket where instead of having one encoder that will run for most of a live stream's life and occasionally need to pass its data off to a different encoder, instead we have a new encoder for every segment and the failover is continuous.
And like a lot of things, things that happen continuously are a lot easier to make reliable than things that happen irregularly.
Certificate expiration is a great example of that kind of thing on a different side.
This is kind of similar to how Cloudflare in general works too, right?
Like Cloudflare, you make requests and then everything happens on a request basis.
And when something needs to get updated, it's very easy to update it because requests happen all the time.
Yeah, absolutely.
The request-driven model, it makes things a lot easier to think about and it makes things a lot easier to test.
And it's worked well for us, to be honest.
Thank you.
I think that's incredible. We've gotten some viewers commenting and then wondering if we could touch upon a few things, things like HTTP3 for delivery for low latency.
I think it's a good segment because you were just mentioning how even a two-second delay, it's not going to be feasible.
So I was wondering if we could talk about that a bit more.
We can talk about that, yeah. Oh, you mean HTTP3 for delivery- For low latency and for more scale, so that the viewer requests.
Yeah, sure. So while Cloudflare already supports HTTP3 and the service already uses HTTP3 and it's open beta, so you can go use an HTTP3 today.
But for low latency, so this is a very good question.
So for those who don't know, HTTP3 is the new kind of HTTP standard that uses a new transport protocol called QUIC.
And QUIC is more suited for applications that might use lower, that require lower latency when delivering something.
For example, the time that my camera records this content to the time that your screen shows.
And then if, say, if you want to ask me a question so that doesn't get delayed, you want a lower latency connection between my camera and your screen.
And HTTP3 is one of the things that can make the shorter. The product we're launching today is definitely not meant to be used for video calls or some things that are very short.
And we actually have another announcement, I think another Kafka TV show, where we're going to talk about that more closely.
But yeah, this is definitely something we're exploring.
There's so much, so much we can do.
So much we can do in general, and so much we can do because Kafka controls all the aspects of the networking and all the ingestion of the video and the delivery of the video and every single part of it, Kafka controls.
So there's so much we can do to improve that.
And a huge part of that is utilizing QUIC and utilizing HTTP3 and also other protocols.
So yes, is the answer. Got it. Thank you so much. So whoever was listening and asked that question, I hope you got that answer you wanted.
Anyway, let's continue with something I've been wondering for a long time.
I know we dog food our products a lot. So I was wondering what Cloudflare products did you use to build live, stream live, I mean?
Yeah, I can take this one. So for a long time, stream had the distinction of being the heaviest Cloudflare Workers user out there.
We were the biggest user of Cloudflare Workers and Cloudflare Workers are our edge workers.
And so we continued this pattern of using workers a lot and we're using it to manage kind of what Kyle referenced, which is we're like chunking up the live stream.
And so we're doing ingestion and then we're doing the encoding of these little few seconds of video and then also doing delivery.
And that's all happening with Cloudflare Workers. And then one new thing that we started using was Cloudflare announced objects.
What is this? Durable objects.
Yeah. And so it's like Cloudflare workers were always meant to be kind of like stateless, right?
Like it just runs something and that's that. And I don't know when the announcement was, I think it was earlier this year, but it was introducing an object storage on the workers.
And we're like, that's great because we need some state that we need to store about the video and how it's like progressed, like which part of the stream we're on.
And so we're using durable objects and it's worked really well for us.
So highly recommend if anyone wants workers with state.
And then of course we're using Cloudflare network because everything's on the edge.
Cloudflare has 250 plus what we call points of presence or pops.
But it's just they're all over the world where we can like serve this traffic and we're able to route through another product called Argo.
And it's also like called like the ways of the Internet, which is like it's smart routes, your traffic to be delivered from the pop that is closest to the viewer.
And that's really important for live streaming because people care about latency.
Like Kyle mentioned, if you're like really laggy or you're getting a broadcast and you're like 30 seconds or a minute behind, and you, I don't know if you've ever had this experience, like where everyone's watching something live and people will hear like cheering in another room and you know, your broadcast is slow.
Like a goal was scored or something like we want to be the one that's in the room with the cheering.
Right. So that's kind of cool because we have like all this network infrastructure and Cloudflare products that really optimize for speed and for proximity to the viewer.
And so like building a live product on top of this just really made a lot of sense.
Thank you. I think the pain you mentioned is something all of us would have felt at one point.
So it resonates truly with me. I don't want to be in the room where the goal is not reflected immediately.
So thank you for sharing that.
I was wondering if we could talk about how to use StreamLive.
I know a lot of, we have a lot of customers already for you know, on demand stream.
So how should we be using StreamLive? Yeah. So to give you a high level overview, at launch StreamLive supports RTMP.
I want to be really clear because the vision that we have for StreamLive is not protocol specific.
It's actually, you know, protocol agnostic.
And that's really big because the other, you know, products or point of view that other cloud providers take, their products are often segmented by protocol.
So if you want to do, if you're going to use this protocol, there is this, you know, protocol A, there's a different product than protocol B.
And yet when you take it again, zoom out and you look what these protocols are doing, they're doing some form of video, right?
With different latency standards or possibilities, but it's still video, it's moving pixels.
And after the fact, you know, there are, there's a huge overlap of needs, such as recordings and things of that nature.
So we're launching with RTMP, but we have plans to support many other protocols so that you can pick and choose depending on the use cases and the constraints you have, which protocol to use.
And know at the back of your mind that after the live event ends, no matter, irrespective of the protocol, you're going to have a recording of the video available.
So with that said, I'll share my screen real quick to give you a quick walkthrough of how to use StreamLive.
So StreamLive uses the same dashboard as the Stream product. Really it's the same product.
StreamLive is an additional feature of the Stream product that we've had for three years.
To get started, once you go into your Stream dashboard, you would, you'll see a new tab called live inputs, and you can create an input.
So we can create an input, give it a name. By having this toggle on, what this means is as soon as you start pushing RTMP to us, we will create a live video that you can embed or stream using your own player using HLS and Dash.
So once you've created an input, you get the RTMP URL. This is something that you would configure in your app or any app that you're using to do the broadcasting, such as OBS or a custom app if you have one, and you would enter the RTMP key.
So this is really the heart of the information that our customers need to get started with StreamLive.
A few seconds after we begin receiving the RTMP feed, this black screen right now that says input is not connected will just begin showing the live stream.
We handle disconnection, so your input ID doesn't change, right?
So the input ID can be reused.
If you have an event every day at 10 a.m., for example, you could use the same input ID, but for each of those 10 a .m.
segments, you will end up with a different live and on-demand video.
So this way, you don't have to go back and deal with one long video.
At the same time, you also don't have to change the input ID.
It's kind of like if you have recurring Google Calendar meetings, it's kind of nice that the link stays the same.
So if you're looking to deliver experiences of that nature, you can do that with StreamLive.
Thank you.
You know, we always say Cloudflare makes things easy to use, but seeing this, it's just a couple of buttons and then there you go, you have it.
It's incredible how we can build that technology and make it very easy for the users to use.
It's amazing. So thank you for showing that. I was wondering if we could also touch upon how does the pricing for StreamLive work?
Yeah, so one of the things that we're personally as a team very passionate about is keeping pricing simple, right?
And what we mean by that is if you look at other major cloud providers, if you're using them at some scale, even if you're not using them at scale, you often end up with line items that are really hard to understand.
It might just be a couple of bucks, but something about seeing, getting bill, even if it's a few bucks for something you don't understand is just comforting, right?
It makes you wonder that, well, it's two bucks now, but could it be 2000 next month?
Especially if I don't really know what I got built for. So what we've done with StreamLive is we've kept the pricing incredibly simple where it's the same price as on-demand because for us, fundamentally, if you think about live, the nature of life is different and that whatever pixels you're seeing, it is happening in real life at like a 10, 15 second delay.
But the tech underneath it or the unit economics underneath it remain the same where you're still pushing data to Cloudflare and you're still using Cloudflare to send data on your behalf for your end users.
That doesn't change between on-demand and live. So that's really our thinking behind keeping the pricing for live simple, where when you begin broadcasting, the videos are automatically recorded.
So if you do a 10 minute broadcast, other vendors will charge you for the broadcast itself for the 10 minutes.
There is no additional line item for the actual, you know, for the live component of uploading video to us.
You simply pay for the video after the fact when it becomes a 10 minute recorded video.
But again, the live portion where often you'll find vendors charge you an additional markup for pushing for the video being live, there is no additional markup for the video being live in the stream, Cloudflare stream work.
Got it. Thank you. So we are nearing the end of the segment.
We have less than one minute left. So what's next for stream live? If you could summarize that very, very quickly for us, it'd be amazing.
Yeah. So, I mean, I think I touched upon this briefly for us, we're just getting started.
I think there's so much to do with live, but what really excites us is when we think of, when we talk to our customers and they describe what they're looking to achieve and for us to be able to go on that journey with our customers and be able to just picture all the possibilities, especially when you start looking at workers and combining that with stream, where our customers can literally, you know, write workers in combination with stream where they're telling, where their code is saying, you know, start a live stream in an idea, in a perfect world, you should just be able to do that.
Right. And in a non-Cloudflare stream world, where you might need to make, you know, think about 30 different configurations, our goal is how do we cut that down by like 90%, right.
Instead of needing to configure 30 things, what if you need to configure like three things or even better, like zero things, if you want a, if you just want something out of the box to get going.
So that's something that we're really looking forward to. I think what we have launched is great for broadcast and we're looking, we're going to continue pushing the envelope and reducing latency and doing cool new things with live.