[Feature] Use webtorrent for save bandwidth

[zodman]

https://webtorrent.io/

[Yay295]

I'm not convinced this would actually help.

1. To work, someone would have to be sitting on the website for quite a while, and they would only be able to seed to people watching a video they'd watched. That website you linked downloads a torrent when you go to it. In the hour I left the page open for, not one other person joined for me to seed to.
2. We have a lot of videos. That means we would need a lot of torrents. This could potentially take up a lot of memory and processing power.
3. This would have to be opt-in. Some people use the internet from their phone, and even many landlines have data caps. Using their bandwidth and data without telling them first would be unethical. Making it opt-in means adding another switch to the menu.
4. This would be one more thing we would have to write code for and support. It seems like the client side wouldn't be too hard, but on the server side we would have to automatically generate and seed torrents for all of our videos, and update them if anything changed. I haven't tried it, but I don't see anything that says their desktop client would even run on a server that doesn't have a gui.
5. We would still have to support the current method for everyone using a browser that won't run this code.

[TimotheAlbouy]

I'm sorry to exhume this topic, but I wanted to address the points you made.

1) That's not it. Webtorrent does not download the video locally on your computer when you watch it (in any case, there's not way in client-side Javascript to download a file on the computer without asking the user's permission like popping up a dialog). What webtorrent does is just retrieve the video as a stream, like you would do with an usual <video src="...">. You don't become a seeder after you've watched a video using webtorrent. If you cannot watch the video on the webtorrent website, that's not because nobody is on the website at the same time as you, it's because everyone who seeds it has their computer shut down. To become a seeder of the video, you would have to purposefully download it and seed it using a torrent client.

2) Whether you store your videos on a server or using torrents, you would have to store them somewhere. Fansubbers share their work mainly through torrents, so there is likely plenty of copies of the same video available. If you are afraid that nobody will seed your video, you can still seed it yourself so there is always a copy accessible. When you think about it, serving a video on a webserver or running constantly a torrent client to seed this same video is just the same, and the second option might even save bandwidth if other people are seeding it.

3) See 1).

4) Yes, you would have to write code to implement this, but like for every feature request I might add. Besides, you say that the server-side logic would be quite difficult to do, but you don't even need one. Webtorrent can work client-side (only if you use webseeds). And if you want to generate a webseed programmatically every time a new video is uploaded to your server, you don't have to use any GUI, you can do all that in Node.js using exactly the same module, webtorrent.

5) If you use webtorrent server-side, the browser support would be the same (that's just a HTTP request to your server to retrieve the video). If you use it client-side, fair enough. Webtorrent uses quite advanced specifications like WebRTC, but what you already use for ASS rendering is also quite advanced for really "old" browsers (CSS3, SVG filters, ...). In any event, webtorrent is well supported for all the major browsers like Chrome, Firefox, Opera and Safari.

Then what are the issues of webtorrent?

As I said, if you use webtorrent client-side, there is an important limitation to be considered. On the browser, webtorrent uses WebRTC for peer-to-peer transport, so this isn't like a full-fledged torrent client that uses the TCP protocol (OSI note: web browsers are on the application layer, so they cannot access protocols on the transport layer). So what I mean by webseed is a torrent seeded with a WebRTC-abled torrent client (like Vuze or the webtorrent client). Clients like μTorrent or BitTorrent don't implement this feature unfortunately, but we hope it will be sometime soon. But even then, you can still use the server side version of webtorrent that works just like any other torrent client. I don't know if you could still stream videos though.

Besides, webtorrent can only stream videos in .webm or .mp4. Fansubbers files shared through torrents are often .mkv because this format can embed ASS subtitles, so they cannot be streamed with webtorrent. What it means is that you would have to first download the video entirely before displaying it. You would also have to use some library to demux the .mkv to retrieve the ASS file. But I assume this wouldn't be a problem for animeopenings.moe because you already store your videos in .mp4 or .webm.

[QuadPiece]

I'll just drop in as the one responsible for servers (and so by extension, bandwidth optimization)

We currently run a custom "Mini-CDN" in Ameria can Europe consisting of servers with SSD storage and uplinks higher than 100 Mbit/s.

Bandwidth is certainly one reason why we have multiple servers. But another reason why we run multiple servers spread out instead of one cheaper, big box in Europe with a fat uplink over 1 Gbit/s is because of the time to playback.

I'm not super familiar with webtorrent, but I assume it would save bandwidth. However, for a good experience on a site like openings.moe where people can rapidly shuffle through videos simply by mashing the N hotkey, one thing that matters just as much, if not more than having excess bandwidth, is TTFB.

From my experience, the worst drawback of torrent streaming compared to regular http streaming tends to be TTFB. Even if you have webseeds you can download from, I assume you would need to use JS to create a torrent-based video player object and such prior to starting playback.

Having a 2s start time instead of 0.5s start time wouldn't be a problem if we were a site like YouTube with 10+ minute videos and people who go on long watch sprees. But openings.moe's usage is quite different. It's commonly used for rapidly shifting through content. I even know of people who use it for drinking games (Play video, first person to guess the anime takes a shot, then press N to get a new video).

In openings.moe's use-cases, TTFB for video playback stacks up quite rapidly. If webtorrent negatively affects TTFB, it's not something that would be beneficial to us. And if keeping the TTFB low across the globe with webtorrent would require us to keep SSD caches near users anyways, it'd pretty much zero out any potential benefits as we'd need to keep all the servers running anyways.

I'm more sysadmin than dev, so I'm not familiar with the specifics, but when visiting https://webtorrent.io/, it takes 2-4 seconds for the video to start playing, such times wouldn't really work for openings.moe.