Cloudflare seems fairly expensive for on-demand (that is, uploaded ahead of time) video. They list their prices as $1/1000min delivered plus $5/1000min/month stored. I presume transcoding is included in those rates (since I don’t find any other line item).
Translate Bunny’s pricing <https://bunny.net/stream/> to these numbers: $1/200GB delivered (assuming the volume network—the standard network is 2–12× the price, but I would not expect it to be justified) plus $5/500GB/month stored, and transcoding is included in those rates.
Bunny is cheaper to deliver below 26⅔ Mbps, and cheaper to store where the sum of all transcoded forms is below 66⅔ Mbps. This will almost always be cheaper, normally much cheaper. It depends on the content, but your 1080p60 video is almost always under 10Mbps, probably under 5Mbps, not uncommonly well under 2Mbps. Your bill with Bunny will probably be less than a third of your bill with Cloudflare, and for typically more static sorts of content (e.g. programming tutorials), probably less than a tenth.
(I am presuming the products are roughly equivalent. This may or may not be true. I have used neither.)
I should also mention that Cloudflare’s sample pricing uses grossly unrealistic rates: they translate “500 GB of HD videos” into “1,200 minutes of video content”, which means 55 5⁄9 Mbps. “HD” tends to mean 1080p these days, though it does still get used for 720p too. (Some label 1440p and 2160p/4K as HD too, but I’d say they’re beyond it.) I accuse Cloudflare of using a rate that’s around four times too high. They don’t go into detail on their “typical public cloud provider” costs so I don’t know how realistic the rest is, but given how they’ve started with something that makes them look implausibly cheap, I’m not impressed.
I considered that possibility, but decided the wording is fairly clearly referring to pre-transcoding library size (“500 GB of HD videos”).
On reflection, it’s possible that there was a miscommunication that led to this wording, since if it were the post-transcoding figure it wouldn’t be outlandish for something like VP9/H.264/AV1 at 1080p/720p/480p/360p, though it’d still be on the high side.
> Get ready for a nice bandwidth bill if anyone actually watches your videos!
This 100%
I looked into it before and understandably, the badnwidth you can be using up for a relatively small amount of videos is always going to be pretty expensive. It is also not always easy to know in-advance, and do you want to suddenly get a 10x bill or have to cut-off your users when it gets expensive?
If you can afford to charge, then obviously it's different, otherwise YouTube's annoying advertising is paying for you...
2) Why? There are plenty of blogs walking you through how to use FFMPEG to generate multibitrate HLS packages. I get faster than realtime encoding making 5 different bitrates.
2->1) Now you're only storing the highly compressed versions instead of the original (at whatever compression chosen for that)
The most basic pipeline for doing it is going to look something like this:
1) Upload the original video to a storage bucket.
2) Have some compute service transcode the video file to create other renditions.
3) Store those renditions in a different storage bucket.
4) Put a CDN service in front of the transcoded renditions.
Get ready for a nice bandwidth bill if anyone actually watches your videos!