[lordnacho]

This is still just streaming a static file though. Adjusting which segment to get will work, buffering will work, and people don't mind their movie starting a few seconds after they press play.

If I'm streaming live, I need the frame immediately, and it doesn't help much to get later frames after the frame I'm missing.

[Protostome]

Live streaming is, by nature, a "one-to-many" distribution model, where content flows from a single source to many viewers in real time.

BT, on the other hand, is fundamentally designed for "many-to-many" distribution, where peers share pieces of content with each other over time. This isn't just a question of tweaking the protocol—it's a fundamentally different problem. Unless you're willing to compromise on the immediacy of the stream, using BT for true live streaming isn't really a good fit.

[jack_pp]

what if everyone agrees on a 10s delay?

[lordnacho]

For pseudo-live streams such as sports events, that would be totally fine. People can have slightly out of sync streams, delayed by various amounts.

But you can't live stream a conversation with someone if you have a 10s delay.

[duskwuff]

Latency is actually a pretty big deal for live sports events.

No one wants to hear the cheering start at the neighbor's house ten seconds before you get to see the team score a goal.

[lordnacho]

And yet, that is exactly what we have!

[bawolff]

The issue is everyone is watching the same part of the file at the same time. Offsetting by 10 seconds does not change that.

[Timwi]

The time offset impedes the ability of viewers to interact with the streamer via chat, which for many people (incl. myself) is the whole reason to watch live instead of a recording.

[delusional]

Define "live".