this post was submitted on 13 Jun 2024
596 points (96.4% liked)

Technology

59111 readers
5621 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 1 points 4 months ago* (last edited 4 months ago) (1 children)

I want to see how you can serve thousands or millions of people with a Chromebook in your closet. And if you say p2p, that doesn't deal with spikes in demand and a lot of old content will just vanish even easier than on YouTube. Also it would rely on people being willing to seed.

[โ€“] [email protected] 0 points 4 months ago

The main limitation is the 1 gigabit network. It can push out 260 3megabit streams or 50 15megabit streams at the most.

That's already an enormous amount of concurrent viewers that covers 99% of content on youtube.

To achieve this, you can't be wasting processing power anywhere, a straight copy to network from pre encoded files, no live transcoding.

No scripting, no encryption either. If you really need that, which you almost certainly don't, then install a recerse proxy on your openwrt router.

Now, if you want to scale, which almost no video really needs, then you'll send the client a script. The client is a source of inifinite scaling, compute and bandwidth.

Each client just needs to rebroadcast two streams of the file.

As excess clients connect, you tell them to get the stream from the stun/turn server. This punches through both sides of the nat. And puts two clients in communication. First client sends its copies of the received stream chunks, with preference from the beginning of the file. One client can get the stream from multiple other client and once it has a few stream chunks in the cache it can serve them to new clients.

It doesn't take many doublings before you have more bandwidth than the whole internet. All the logic for organisation, hash checking, stream block ordering etc etc is a small text file from the server, signed by the server's certificate. It runs entirely inside the client's browser.