Streaming video over BitTorrent - Uncensorable but harder to use

[hundredpercent]

Every day, the censorship gets stronger. We may be granted some respite, but centralized services are eventually wont to fail. For social media, forums, etc., federation offers an acceptable solution, but for livestreaming the expenses are simply too great to shoulder.

The only technology that's worked thus far for file-sharing (in spite of all its flaws) is BitTorrent (https://en.wikipedia.org/wiki/BitTorrent). If you have been living under a rock, BitTorrent allows you to share files without a centralized server by forcing the people who download ("leeching") to also upload ("seed"). Nobody has ever come up with a good replacement for BitTorrent without these flaws (leaks IP, needs special software).

Could we do something similar for livestreaming?

---

Technical

The most common livestream protocol today is HLS. HLS is used everywhere because it allows you to re-use ordinary HTTP CDN infrastructure. HLS replaced RTMP, which required specialized software to properly stream.

HLS works like this:

1. Every second, check the stream URL for a list of videos (m3u playlist)
2. Each video file is like 4 seconds long. There's like a thousand video files in a hour long stream.
3. Every few seconds, a new video file gets added to the end of the playlist
4. The file server with the videos doesn't need any special adaptations for livestreaming

In other words, there's two servers. A main server, that just gets you a list of say 100 video files (last few minutes), and a CDN server, that just serves random files it's fed by the backend.

The main server is (comparatively) cheap to run, and the CDN can be run on commodity infrastructure.

So here's the idea I had: instead of having the playlist contain links to mp4 files, you link to torrents. A torrent costs ~nothing to create, and is fast to download in large numbers. Sure, it'll take a few seconds, but that'll just manifest as stream delay.

(It might even be faster if it's well optimized, since there's less intermediate servers)

---

Implementation - client

This idea seems extremely simple, which leads me to wonder why anyone hasn't done it yet.

I don't want to rewrite the HLS spec or make a whole new video player, so something that works in VLC would be ideal. You'd need to point VLC to an URL that has a m3u feed with (HTTP) links to mp4 files.

My first idea was to have a local torrent client, and have the remote server feed you the feed, and VLC queries the HTTP links in there, and those point to something like localhost:1234/torrent_hash. On localhost:1234, there's some torrent client that GETs whatever you point it to and feeds it over HTTP.

This has some problems:

1. You have to hardcode the port:IP pair
2. Anyone who can make GET requests to localhost can make you download arbitrary torrents

So, I'm thinking you have a local application that provides a HLS stream to VLC/mpv. The local application also downloads torrents, but theoretically these parts could be separate.

The application would poll for a new HLS stream, as well as a list of all torrents for the stream. It would get the infohash of the torrent, and associate it in a map that goes infohash -> metainfo.

Then, when localhost:1234/infohash is queried, it already has the metainfo and can start downloading.

This means scrolling would work properly.

(In the distant future, you could get the HLS over DHT/gossip too, but it would be a lot of work for a first draft, I think Tor or something would be good enough)

You could also have some mechanism where it starts to download new torrents as they come in, as a cache.

This still doesn't seem that hard, though. It seems seductively easy.

You could add chat trivially, just add an IRC client.

---

Implementation - server

This is actually much easier.

1. Provide RTMP sink
2. Transcode RTMP to HLS
3. When a HLS chunk is done, run mktorrent and:
   1. Load the torrent file into the torrent client
   2. Push the torrent file out to the users
   3. Add the infohash to the m3u8

If you want chat, just integrate IRC. Server masks IPs. Ident handled by nickserv, or not at all (bitwave/4chan style)

---

What I worry about

This isn't gonna be a drop-in replacement for Twitch, just as uTorrent isn't a drop-in replacement for MegaUpload. To wit:

1. You'll need to install software. (Web-based torrent is shit; BitChute gave up on it totally, and PeerTube just falls back to the CDN)
2. You'll leak your IP. In practice, people download lots of torrents and nobody seems to care. People don't care about their IP being exposed for coomer stuff, even.
3. Performance and stream delay might be bad.
4. I don't see how you're going to support adaptive live streaming, where you vary the quality. I see two choices:
   1. Users download qualities they don't actually want to seed them (inefficient)
   2. You do some encoding black magic to get something like a progressive JPEG with the 16kib chunks (hard?)
5. This won't work very well on mobile (but not impossible)

---

What might go well

Livestreaming isn't limited to politics stuff. As I see it, there'll be three main audiences of this software:

1. Political extremists, who can't get hosting anywhere else.
2. Sports fans, who want to illegally stream sports.
3. Coomers.

In the best of worlds, third worlder sports fans would develop nicer software to use it on phones etc, and coomers would set up some public HTTP frontends for it (think seedboxes).

Again, this would not have the mass appeal of Dlive/Trovo, at least not initially, but it's better than nothing, it would be extremely robust and provide an absolutely certain "lowest level" below which you'd never cross, and you could use it as a backbone to build more robust services (like in the soccer example above)

---

Questions

What I want to know is this:

• Did any projects try desktop-based torrent livestreaming?
  • Why did it fail?
  • https://github.com/pldubouilh/live-torrent - Here's a WebTorrent PoC
• How low can you get the starting latency of a torrent?
• How many specific hacks (pre-seeding peers, pushing torrents over WS, preloading torrents) are you going to need for OK performance?
• How much software will you be able to re-use?
• What's the potential to get a good ecosystem to grow around this, that isn't just political lunatics?
• Would this software enable people who are otherwise totally blacklisted (i.e. very exciting political figures) to get a "new voice"?
• Would you be interested in trying this, once I put a beta release together?

Sorry if anything is unclear, wrote it in a hurry, please ask if you have any questions. Appreciate your thoughts.

 

[Never Scored]

 

[hundredpercent]

That's for pre-recorded stuff. This would be for livestreams.

 

[Sam Losco]

Torrents work by distributing a file broken down into many many pieces out of order. You may get piece 523 and then piece 687 while still waiting on piece 1 and from many different people.

How are you going to do that with a live stream that isn't even complete to begin with? You'd still have to have server(s) as seeders and you'd have to force getting pieces in order to avoid drop outs. You're still basically doing HLS just over a protocol that doesn't really work for this type of thing.

BitChute tried and it didn't work for shit so they dropped it and that was for completed videos not even live streams.

It'd be better to come up with a new protocol but you'll always run into the same issues with slow peers, lag and even getting enough peers for it to be usable.

 

[hundredpercent]

Torrents work by distributing a file broken down into many many pieces out of order. You may get piece 523 and then piece 687 while still waiting on piece 1 and from many different people.

How are you going to do that with a live stream that isn't even complete to begin with?

Each individual piece is complete.

You'd still have to have server(s) as seeders and you'd have to force getting pieces in order to avoid drop outs. You're still basically doing HLS just over a protocol that doesn't really work for this type of thing.

You'd need a server for seeding if availability goes to 0, but it should be able to handle the data moving fine. If there's 1000 people downloading, there's 1000 people uploading, etc.

I'm really curious about the dropouts - are you saying they'd choke so fast?
If you have a symmetric 100mbit connection and the video has a bitrate of 10mbit, it should be enough that 10% seed, theoretically.

The worse Internet, the worse your stream delay would be.

BitChute tried and it didn't work for shit so they dropped it and that was for completed videos not even live streams.

BitChute used WebTorrent, which is very bad. This would use normal BitTorrent, which is at least better.

It'd be better to come up with a new protocol but you'll always run into the same issues with slow peers, lag and even getting enough peers for it to be usable.

Can you improve over BitTorrent? Would you have to make serious changes, like making tit-for-tat work across swarms and improving topology?

 

[Not Really Here]

If you have a symmetric 100mbit connection

So very on both speed and symmetry.

Speed test market reports

 

[hundredpercent]

So very on both speed and symmetry.
View attachment 1891043View attachment 1891044
View attachment 1891046View attachment 1891048
Speed test market reports

I'm not saying you have one. If that's an average, it's better than I thought. That should be enough to upload 4.3 10 mbit streams, no? So it'd be enough for only 25% to seed, in that case.

Also, frankly, 1080p isn't needed. If you're just trying to run a stream and don't have anywhere else to go, 720p (~2mbit) is OK. Even less with HEVC, probably.

I'd go with something like:
audio stream @ 200k (same for everyone)
1080p 30fps @ 5mbit (or more) - for >100mbit connections
720p 30fps @ 1mbit
240p 30fps @ 100kbit
"144p" 15fps @ 10kbit

The 144p stream would just be there to have something to show instead of black if the video is buffering.

 

[Smaug's Smokey Hole]

I'm not saying you have one. If that's an average, it's better than I thought. That should be enough to upload 4.3 10 mbit streams, no? So it'd be enough for only 25% to seed, in that case.

Also, frankly, 1080p isn't needed. If you're just trying to run a stream and don't have anywhere else to go, 720p (~2mbit) is OK. Even less with HEVC, probably.

I'd go with something like:
audio stream @ 200k (same for everyone)
1080p 30fps @ 5mbit (or more) - for >100mbit connections
720p 30fps @ 1mbit
240p 30fps @ 100kbit
"144p" 15fps @ 10kbit

The 144p stream would just be there to have something to show instead of black if the video is buffering.

You would probably want a number of trusted "top peers" to do the initial seeding/distribution from. 5-10 top seeders that can seed to 10-40 clients each to get and keep the ball rolling, do the (speculative) math on that and guesstimate how far that gets you. Yes, I see the problem with this in a system that is meant to be decentralized but it could be done on home connections instead of AWS, potentially through a VPN and virtual machine. Someone like Alex Jones wouldn't have a problem to set that up directly or have his userbase volunteer bandwidth and usage of their NordVPN.

You might also want to cache everything on every machine or put in safeguards so a group of people can't wreck the system/stream by rapidly jumping around the timeline and requesting chunks at a rate that far exceeds requests of real viewers.

 

[biggest big boy]

dancing through the jew's hoops is for nigger cattle and if you play this game you will be playing it for the rest of your life.

ensure fair access to finance services and never worry about faggot dweeb shit like this again

 

[Dick Justice]

It's already difficult enough to maintain a healthy swarm and now you want to add a bunch of freeloading leeches?

 

[hundredpercent]

You would probably want a number of trusted "top peers" to do the initial seeding/distribution from. 5-10 top seeders that can seed to 10-40 clients each to get and keep the ball rolling, do the (speculative) math on that and guesstimate how far that gets you.

Yeah I mean, the optimal is obviously to have a optimal network topology. Take all the nodes, sort them by network speed, and have everyone distribute to the one on the top of the list. In practice, that's not possible, but it's the "God's algorithm" solution.

The second best is that the initial seeder uploads to the fastest nodes, and they just upload wherever. I don't see how it makes any difference who controls them.

There is a modified version of BitTorrent (BitTyrant) that does this, (BitTyrant is similar but not exactly the same and wouldn't work well here) but it would be more work for an initial proof of concept. That can trivially be bolted on later, I'd think. You can see their speed you're uploading to them, so you can estimate their network speed.

Although if you do that, it might open you up to attacks. Some more "random" system seems better for that reason. (When you start to get actual attacks, I'd imagine you'd have to do something like seeding less to known datacenter IPs or whatever)

But it's not that big of a deal. If the initial seed has 50 peers and 49 are malicious, but 1 peer is honest, then all you're doing is adding some latency. If it's a 5mbit stream and that peer has bandwidth of 100mbit, he can seed to 100/5 = 20 clients. Such an attack only adds a latency of 5/100 = 50ms.

Yes, I see the problem with this in a system that is meant to be decentralized but it could be done on home connections instead of AWS, potentially through a VPN and virtual machine. Someone like Alex Jones wouldn't have a problem to set that up directly or have his userbase volunteer bandwidth and usage of their NordVPN.

If you had two people on gigabit lines, and the stream is 5mbps, they can directly reach 400 people. So it's not a big problem. If you have 1000 random people watching, some of them will probably have really fast Internet connections.

You might also want to cache everything on every machine or put in safeguards so a group of people can't wreck the system/stream by rapidly jumping around the timeline and requesting chunks at a rate that far exceeds requests of real viewers.

It'd be cached for as long as it's cached. If you try to request an old chunk, it'll either work (someone's seeding it) or it'll fail (nobody's seeding it). It wouldn't cause any problems, just like it wouldn't cause any problems if someone tries to download a dead torrent.

What you probably should do is prioritize uploading newer chunks first. Anything after ~1m should have the same (low) priority.

dancing through the jew's hoops is for nigger cattle and if you play this game you will be playing it for the rest of your life.

ensure fair access to finance services and never worry about faggot dweeb shit like this again

Thank you for your actionable advice. You're gonna see a hell of a lot worse than credit card blacklisting real soon, I'll tell you that much.

It's already difficult enough to maintain a healthy swarm and now you want to add a bunch of freeloading leeches?

This wouldn't impact normal torrents. I imagine that the reference client would seed it, because the cost of doing so is nearly 0.

The problem with normal torrents isn't that people don't seed while downloading, it's that they don't leave the torrent on after that's done. Retention, not bandwidth. Retention I don't really care about, it's bandwidth that's important.

 

[biggest big boy]

Thank you for your actionable advice.

here's some more,, grow a penis

 

[XYZpdq]

this sounds like one of those things where if it all works perfectly it would work okay, but when the IRLs hit it then it will crash and burn

 

[Dante Alighieri]

dancing through the jew's hoops is for nigger cattle and if you play this game you will be playing it for the rest of your life.

ensure fair access to finance services and never worry about faggot dweeb shit like this again

That's not how it works, retard.

 

[hundredpercent]

this sounds like one of those things where if it all works perfectly it would work okay, but when the IRLs hit it then it will crash and burn

I mean, feel free to rate this Optimistic, but people have tried to shut down BitTorrent, and they all failed. The Christchurch shooting torrent is still going strong. So it seems at least reasonably robust.

 

[XYZpdq]

I mean, feel free to rate this Optimistic, but people have tried to shut down BitTorrent, and they all failed. The Christchurch shooting torrent is still going strong. So it seems at least reasonably robust.

Yeah the core idea of torrents work, I'm just saying this particular application.
Like as soon as a couple of people are in the food chain on a wireless lan instead of wired there's plenty of opportunities for it to shit itself

 

[Never Scored]

That's for pre-recorded stuff. This would be for livestreams.

Most of the political live streamers just read articles and talk about the news. Why not just do audio streams? Audio encoded at 64 kb/s a second is acceptable for talk radio:

You'd be able to stream to around 15 listeners per megabit of up speed. If you have fibre internet with at least a constant 100 up speed, realistic with most fibre internet packages, you could reach over a 1,500 listeners on there just streaming from a computer in your basement and you don't have to ask people to seed a video of someone saying nigger over and over again. What's so important about having video?