Remix clone Hacker News

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 5 days ago | parent | next [-]

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 5 days ago | parent | prev [-]

what if everyone agrees on a 10s delay?

▲

lordnacho 5 days ago | parent | next [-]

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 4 days ago | parent [-]

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 3 days ago \| parent [-]
		And yet, that is exactly what we have!

▲

bawolff 5 days ago | parent | prev | next [-]

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 5 days ago \| parent [-]
		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 5 days ago | parent | prev [-]

Define "live".