Building Cloudflare TV from Scratch
blog.cloudflare.com
blog.cloudflare.com
Personally, I would almost always prefer a blog format over a live segment. If it is a live segment, then I’d hope I can at least watch the recording later.
I’m curious about engagement. Is anyone watching this? Does anyone seem to actually care?
Resliable and scalable distribution platform for live video that plugs into existing tools could be of an interest.
src: https://twitter.com/cloudflarehelp/status/127293910658317107...
You don't need to move it around the world (TCP can start to bite you, but most likely you are just wasting someone else's network resources) but you can definitely move it away from the nearest POP if it is getting loaded. You can even do clever things like shard by chunk ID across warm POPs so that you get better cache utilization and reduce disk load.
https://blog.cloudflare.com/ladies-and-gentlemen-cloudflare-...
Perhaps the elephant in the room is "what's next"? Seems like it could at least become a Twitch competitor, if not also to YouTube if Cloudflare is able to figure out the monetization, privacy and copyright aspects.
If that was the only problem, why wouldn't changing the stream with a small amount of JS have worked rather than having to add a muxing layer in front of the streams?
> Bring Cloudflare TV to platforms like Apple TV and Roku
2. Given this is Cloudflare they are probably trying to find optimal ways to use bandwidth and their edge fleet. Like TV, maybe there will be no "rewind", and each Cloudflare edge server fans out the same "currently live" bytes to all available clients (i.e. shared state across all client connections, rather than independent state for each client connection). Which can't happen if there is a "refresh" event from each client that needs to be synchronized.
3. "refreshing" implies new state, added latency, and a "janky" feel. If "transitioning" is all server side, bytes from the next "episode" can be pipelined before the previous episode is finished and the refresh event has occurred.
|-Episode A->|
|-Episode A->|
|-Episode A->|
| <-|
| <--Refr|
|<--Refresh--|
|-> |
|de B-> |
|-Episode B->|
|-Episode B->|
|-Episode B->|
Rather than: |-Episode A->|
|-Episode A/B->|
|-Episode A/B->|
|-Episode B->|
|-Episode B->|
|-Episode B/C->|These are the causes (among many others) that sunk Microsoft's Mixer and potentially Facebook Watch...
How? YouTube videos aren't all that prominent on Google and its search features are rather terrible.
What they do have is a semi working recommendations system. How hard would that be to replicate?
”$1 per 1,000 minutes viewed, $5 per 1,000 minutes of video storage”
Many years ago I remember that YouTube reported that 24h of video was uploaded every second. This means that your storage cost would increase by $432/s or $37M/d. This means that you are paying 14B/month by the end of the year just for storage.
Of course there are a number of factors that will work in your favour here: - You can attempt to focus on only hosting "popular" content instead of allowing anyone to upload. However this can make it difficult to draw new creators to the platform. - You can definitely negotiate a better rate.
However I'm still under the impression that if you want to create a YouTube competitor you are probably better of starting with lower level components so that you are in a position to reduce costs for old and low traffic videos. My impression of Cloudflare Stream is that it is aimed for people sharing a relatively small amount of content (probably just their own).
I need a simple API that would allow both a basic user with browser and a webcam, or an advanced one with OBS (RMTP...) to just live-stream as part of my product. And building everything at scale is just super painful.
That's exciting that it's become so accessible.
Of course the hard part then is having a producer running the content all day + getting enough content.
If I'm managing a local access/community TV/open studio system right now, I'd be pulling as much inspiration as possible from this post and working to deploy something similar ASAP. Those places already have the content, and their cable and broadcast reach is either less viable or actively reduced each year.
If so you can reuse everything that the satellite TV industry (one single feed being broadcast across the entire continent) for their pay-TV DRM.
You have to handle key rotation and a thousand other variables, it's a very different environment.
Netflix themselves probably couldn't care less; they know that everything they offer for streaming will be available for pirating the second its released, with or without DRM; people have Netflix because its convenient, not because they cannot pirate their content.
But there is one real benefit of DRM, cracking it is illegal. Of course my understanding is that they would get the exact same legal protections here if they just XORed every byte with 0x42 so it doesn't justify the spend, user inconvenience and complexity of current DRM systems.
So 24x7 monitoring of developers' screens overseen by the world? RIP devs X_X
Has anyone online ever done a “so what you mean is..” and got it right?