It is pretty rare in 2021 to serve video just as "video files". HLS and DASH allow for adaptive quality streaming for bandwidth- or performance-constrained devices -- which can also help keep costs down, if you're shipping lower bitrate 480p renditions to some clients rather than full-boat 1080p -- and make resumption of partially played media easier. (Because you can append segments to an HLS or DASH manifest, you can also use this technology more easily for live-streamed content.)

This stuff is complicated. You can build out the pipelines to do this stuff yourself with either cloud services or a lot of duct tape -- I've done it before -- but it's A Lot Of Work to get right and economies of scale are a real thing. There exist services like Mux Video (YC W16, https://mux.com -- this is a shameless plug; I work on the devex team) package this and present straightforwardly consumable APIs for folks who just want to ship decent video at a reasonable price.

We need something like bit torrent for video, where the peers send chunks biased toward the beginning of the video. This would spread the bandwidth costs to the viewers. Sure, the main site might be constantly streaming 1 or 2 full streams, but that can be fairly low bandwidth.

1) Orchestration of this is not trivial, and creates new points of centralization. Who runs your moral equivalent of a tracker/DHT? How do they keep the lights on for your relatively niche video? There are social differences between the infrastructural audiences of BitTorrent and a hypothetical general-purpose video tracker. If the idea is that everyone runs their own, you're getting into latency-sensitive problems of coordination (and given the push towards static sites, make me ask "do we expect people to have the capacity to do this?") that strike me as tricky given the requirements of video streaming.

2) This assumes that clients are both willing and able to do peer-to-peer transfers. I wouldn't bet on it.

3) This assumes that clients keep old chunks around for the purpose of peer-to-peer transfers (and don't evict things when under memory/storage pressure) and adequately update the tracker with what it has available at all times. I wouldn't bet on that being a reasonable assumption.

4) This assumes clients are reliable and have reliable upload. If you don't get a chunk from that peer client fast enough or that client disappears before you can handshake with another one and get that chunk, you have a video drop. Video drops are a game-over condition in 2021. Which probably seems unfair to say, but something like this has to present a better solution for clients, not for content providers, and this strikes me as really not viable for clients. Otherwise, people leave.

Video is really, really hard. It wasn't until I built a pipeline myself (not a fancy one, either) that I realized how nasty it was. Slinging huge amounts of data around with stiff latency requirements seems to lend itself to more vertical scaling than this approach suggests.

Some of the most expensive cloud bandwidth is AWS egress, which costs $0.09 per gigabyte for the most expensive band [2]. So we're looking at $70 per video. Plus of course the price of your time to get everything set up and working right.

Of course, you could undoubtedly get lower prices - either with an 'unlimited traffic' VPS if you're a small user, or by getting into a cheaper CDN pricing tier if you're a large user.

[1] https://www.youtube.com/watch?v=oROPkh6YosE [2] https://aws.amazon.com/s3/pricing/?nc2=type_a

And, as peer says, discoverability unless you already have an audience.

If you are using AWS, Google, Oracle, or Azure and are just using VMs, you are getting horribly ripped off. There is absolutely zero advantage to using these for just compute. None. They only make sense in a business setting if you are leveraging their managed services to save on labor costs, or if you need to elastically scale to really enormous sizes and have confidence that you won't run out of resources.

VPS providers like Digital Ocean, Vultr, or Linode charge for bandwidth overages but their costs are generally at least an order of magnitude less than the big cloud vendors.

If your primary concern is cost consciousness, and when your failure case is "get slow and fall over" and you're OK with that, this makes sense. For the OP, who doesn't seem to have a profit motive, I think this is good advice.

The caveat I would add is that a lot of folks try to extrapolate from personal stuff into the small-business (opposing "startup" -- that is, not swimming in VC money) realm, and it's easy to staple your hand to your face when looking at video in that way. Balancing cost controls against quality of service is kinda pretty hard for video because engagement is tied in pretty tightly to time-to-first-frame and to consistency of the video stream coming down, and even a well-provisioned set of boxes in an OVH datacenter somewhere are going to have more trouble with latency as well as bandwidth to geographically distributed clients. Yeah, you can fix this...by building your own CDN out of multiple points of presence at multiple data centers, but there are economies of scale to just paying your local friendly CDN overlords to ship your stuff from their POPs. Not all video usage is directly tied to revenue, though, which is why I characterize it as risk: the particulars of your venture may be such that the risk of higher costs due to sudden popularity is worth the quality of service during the 99.9% period for your users who aren't local to your point of presence. But there are no hard-and-fast rules here.

But, yes, in general for an individual hobby site, I'd choose an option that resulted in a hug of death rather than a big bill.