Comparing bandwidth usage with webseed streaming and direct http streaming

[daeschlerdavid]

Hello,

I am currently thinking of using webtorrent to stream videos on my website and save some bandwidth.
My videos are stored in an object storage service (like S3 or google storage). You probably know that with this kind of service I am paying bandwidth usage per GB sent/uploaded.

So why not using my object storage public URL as a webseed in order to save money ? It works great, but actually I think I will spend more money by using webtorrent.

If I stream the video directly from the public HTTP URL, video data are sent just "as fast as necessary" to keep the video stream fluid. Even if I have a very fast internet speed and I watch only 10% of the videos, there will be only 15%-20% of the videos bytes sent by the storage service.

With webtorrent, the whole video is downloaded at my full internet speed. So more bytes are sent by storage service, and the final invoice will be much higher.

Of course this scenario is true only if there is no other peers available than the webseed URL.

What do you think about this ? Is there anything I can do about it ?

[jimmywarting]

You can definitely save bandwidth by using WebTorrent (if you do it correctly) by only using webseeds when needed

You can add/remove webSeeds manually but there is no logic for auto disable/enable

torrent.removePeer(url)
torrent.addWebSeed(peerId)

It's possible to get how many users there is available from the tracker, how many you are connected to and how fast you are downloading...

[RangerMauve]

I think the problem is that the File portion of WebTorrent doesn't do anything special when downloading media files.

It doesn't look like it downloads just the parts that are getting rendered, but I might be missing something.

It uses the render-media module that invokes createReadStream() on the file for prioritizing which chunks to download.

By default, all files get downloaded in a WebTorrent so you'd need to unselect them all and then rely on createReadStream() to prioritize the chunks. Not sure if that'd be enough either.

[jimmywarting]

ideally you should also download pieces in random order and only do sequential download when stream buffer is low... but there's one small issue i have with that: #1558

Maybe webSeeds could kick in when there are critical pieces needed (critical pieces will be flagged when createReadStream is unable to read the pieces that are not available)

[andreekeberg]

It would be really interesting to create a simple demo that uses a combination of webseeds and (when the amount of peers is to low) simply downloading the file directly using HTTP(S).
Even better would be if this downloaded file would then start seeding on WebRTC to decrease the likelihood of the next user needing to do the same.

Has anyone made something like this, or would there be an interest in this kind of demo?

[DiegoRBaquero]

@andreekeberg https://hackernoon.com/how-to-create-a-swarm-cdn-for-free-with-webtorrent-bfa09d193f71

[andreekeberg]

@andreekeberg https://hackernoon.com/how-to-create-a-swarm-cdn-for-free-with-webtorrent-bfa09d193f71

Not sure if I'm missing something, correct me if I'm wrong but doesn't this example always use a webseed? What I meant was the following quote by @AoEmaster:

If I stream the video directly from the public HTTP URL, video data are sent just "as fast as necessary" to keep the video stream fluid. Even if I have a very fast internet speed and I watch only 10% of the videos, there will be only 15%-20% of the videos bytes sent by the storage service.

And the reply by @jimmywarting mentioning only using webseeds in some cases.

I would however be very interested in seeing some more research into how much more bandwidth a webtorrent download (with a single webseed and no peers) uses compared to a traditional HTTP download!

[WatchSoMuch]

@AoEmaster I liked your Idea, I think if there was an option to limit the maximum speed of torrent to something like video bitrate or a bit higher, we can be sure the bandwidth usage will not be higher than normal http streaming.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.