I’d like to point out that this still has deficiencies compared to Vimeo or YouTube, who transcode the source file into multiple bitrates and adaptively serve an appropriate quality based on the viewer’s available bandwidth and screen size.
This manifests as buffering on slower connections, where YouTube or Vimeo would just downgrade the user to a lower bitrate transparently (or nearly transparently).
An end user today will expect that behavior and have very little tolerance for buffering if their connection is unable to smoothly play the one bitrate the creator published (no matter how fast the CDN is).
Edit: I’m aware that it’s possible to do adaptive bitrate streaming outside of using Vimeo or YouTube (as several commenters have explained below) however this isn’t what TFA describes and I think it’s important to note this deficiency in the author’s described approach to serving their own video.
I used MPEG-DASH to build a netflix-party clone when the pandemic started, mostly following this tutorial: https://www.isrv.pw/html5-live-streaming-with-mpeg-dash. It could easily be adapted to on-demand video streaming.
My solution was pretty janky, but it's an interesting problem space to explore.
video2hls looks awesome, thanks for sharing that! I usually use AWS MediaConvert[0] to do the conversion for me, but nice to see an open-source tool to easily do the same.
I can't think of a device that would support MPEG-DASH that wouldn't support HLS. What are some? HLS has been around for a decade.
I think you're thinking of certain DRM mechanisms. HLS with FairPlay wouldn't work on an Android device running Chrome, just as iOS Safari doesn't support Widevine. But for most of us, we don't need DRM.
Sorry, I didn't think we were talking about native support. I'm just so used to shipping something like videojs.
In any event, nothing natively supports MPEG-DASH. https://caniuse.com/#feat=mpeg-dash Though there is a disclaimer "DASH can be used with a JavaScript library in browsers that doesn't support it natively as long as they support Media Source Extensions." the same is true for HLS, without the requirement of MSEs.
Just want to point out all CDNs support HLS for on-demand assets. It’s just static http files. With HLS you just encode your file into multiple different nitrate files which are then split into small 5-10 second chunks and then wrapped in a text playlist for consumption. The protocol is still just static assets over http though.
Also of note: HLS supports byte range addressing, so you can create the various stream files as single .ts files rather than a collection of segments per stream. A client can use the Range HTTP header to select the window of bytes it wants for the stream/bandwidth slot it wants. This mode is supported from something like iOS 5 and up, and ffmpeg has flags to produce such streams.
If you want good cache hit ratios, you probably want to use segments as files rather than segments as byte ranges. Off the shelf http caching software tends to have filesize limits and may not cache large files in ram or even on disk if they're large enough, and may do unexpected things with range requests like request the whole file, then serve the range to the client. CDNs may be running totally custom http stacks or off the shelf stacks with tuned configs or somewhere in between, but if you intend to use one, it makes sense to build your content so it'll be easily cached.
Everyone is replying to you mentioning HLS, which (as your edit mentions) isn't described in the article.
Which is... a bit shocking. From the title of the article, I assumed the content would be related to hosting video. HLS was the first thing that came to mind and I assumed it'd be mentioned up top. I clicked to see if it listed any HTTP-related considerations I wasn't aware of in addition to HLS.
Turns out it's just an advertisement for a (very non-video-specific) CDN service, with some lines tacked on at the end telling you to use Handbrake (oddly, the cli, rather tham ffmpeg???)
It is a tutorial for stringing together a bunch of tools to transcode a video to multiple formats, upload it to S3, and pull that to a cheap CDN (that does get complimented heavily).
And it spawned a great discussion about self-hosting.
I wonder if that really what users expect? I hate auto-downgrading, I always set quality to the highest option and I'm happy to do other work while video is downloading and buffering.
If I'm watching a movie I probably want to quality to remain reasonably high, if I'm watching a Youtube video of people talking or something where visuals don't really matter I'll take 480p over buffering.
Youtube is pretty decent for that, you can either let it figure out what format to use, or force the resolution. That's a good compromise IMO.
I've pretty much switched over to youtube-dl for video viewing, as I find it to be superior to the web interface in most ways. I get the highest-quality file every time, instead of what their AI thinks I want. I can easily request audio-only or video-only. Download once, watch over and over without using more bandwidth each view. No suggested videos. No recommendations. No comments.
Adaptive delivery could easily be added by converting the files with a video encoding service. Transloadit’s community plan is free and should have enough traffic included for these use cases. Full disclose: I’m a transloadit founder
I hope you can enable doing the vice versa some day. I mean HLS/DASH to single file containers like MP4. It seems that you can't pull segments from remote URLs in M3U file for the time being.
> I’d like to point out that this still has deficiencies compared to Vimeo or YouTube, who transcode the source file into multiple bitrates
This may be generally true, but for any screencast (including the author's use cases), automatically downgrading to a lower quality video based on connection speed is a bug, not a feature.
>This manifests as buffering on slower connections, where YouTube or Vimeo would just downgrade the user to a lower bitrate transparently (or nearly transparently).
As a user, I _never_ want to watch shit quality content and _MUCH_ prefer buffering to it.
Back in the day, you could open a tab, hit pause, go back to whatever you are reading, and by the time you finish that article and maybe grab a cup of coffee, the video is fully loaded and you can watch at your leisure.
These days, all the websites are so smart that they realise that you are not on the tab and load nothing so even though the page is been open for 20-minutes, you still have the lovely privilege of sitting there staring at the throbber every so often, thanks to your work insisting on full VPN tunnelling.
> thanks to your work insisting on full VPN tunnelling
Do work in a VM on your main machine. That way you can have full VPN tunnelling in the VM but the host (and other VMs if you use them) use your normal direct connectivity.
Of course you might be breaking rules in a way that might invite discipline, if working in a highly regulated environment where so measures are essentially dictated by your work's clients, by taking technical measures to circumvent policy, so take care.
This can be easily solved by presenting an option set like "slow/fast/HD" to the user, then stream accordingly. Open source has always been about lots of choices anyway!
Just my anecdote, I'm annoying that non-live video service uses adaptive bitrate. I prefer waiting spinner or degrade quality manually than automatically downgrading to awful quality.
Maybe I don’t understand this, but unless something is encrypted, why does the downsampling have to happen at the source?
Alternatively, is there a way to encrypt something, such that you can apply a transform to the encrypted data to downsample it without knowing the contents of the file?
I don't get it. You can unlist your video on youtube, disable the comments, disable related videos etc. and that solves every problem the author talks about. You can even disable monetisation so a user will never see an ad.
After reading the article, it seems inaccurate to summarize it how you did. In particular, all the videos are now back up, and the Blender channel still does not have ads.
It solves the author's problems, but IMO the biggest risk is having your entire google identity nuked for a reason you can't be told, and having every aspect of G taken with it.
The risk is low, but if it's your livelihood, you would be foolish not to consider the issue. Just like paypal: everything is fine until it's not, and then you are stuck with absolutely no avenue of appeal.
That hasn't been possible in some time (yes there are some hacky ways to get around it), and caused a lot of companies in my extended network to ditch Youtube for embeded videos on their website.
Some of them to Cloudflare Streaming as per my recommendation. Their dashboard is easy enough to use for your typical digital marketer and it spits out an embed script that's as easy to integrate as the Youtube one. They also don't have much traffic, so they barely get above the 5$ minimum charge.
1 or 2 ended up with Vidyard (or a similar for-marketers solution I don't remember the name of). For the rest I don't know what they ended up with.
Most platforms don't actively give rightsholders tools to find offending content, nor do they give "rightsholders" financial incentive to claim content (with no repercussions if they claim more than they own).
That was the first thing that came to my mind too.
For some people there are maybe many different reasons no to go with Google. But the reasons the author put up, are no reason to go with Youtube. It is the cheapest way to host video and then to embed it into your site.
Maybe your content is against the rules of YouTube or you want to have a custom paywall for your premium content. Maybe you just don't want Google to collect data about your users. You will be in trouble when Google cancels your account without prior notice.
We were on the Vimeo business plan, which was supposedly unlimited. Until you hit a certain threshold... we run a fairly popular education site with lots of videos and reached that cap. Our bills went up 10x or so.
For our business I guess it’s still worth paying, but worth being aware that not all unlimited is really so.
One nice feature of Vimeo is you can prevent a video from being accessible (streamed, embedded, etc.) on anything but a list of domains of your choosing.
Mux doesn't have this feature (yet). The best you could do is sign every video and have it expire after X time. This can get quite complicated and is less secure since it's only restricted by time (IP address isn't an option either), but due to the nature of how it works, you need to make the video accessible for a bit longer than the duration of it.
If Mux were to add domain restricted security features, I think I would switch to them because having the option of using a custom player is nice for niche content.
I played around with mux and it was a pleasure to use. However I needed to implement a PPV type experience and unfortunately mux did not have any way to restrict or revoke access to content on a per viewer basis. One of my requirements was to be able to revoke tokens for streams that got shared and detect multiple viewers under the same token but sadly this capability was missing. As for pricing mux is priced very well and cheaper than AWS and many other platforms.
Mux and cloudflare stream are on my list of potential alternatives. We do use this domain restriction of Vimeo. It’s not fullproof but definitely stops casual downloads.
Our own videos have been pirated already and are shared around some torrents sites and on telegram, and there's nothing we can do besides plead to people's sense of moral duty. We're not a huge Hollywood studio or a megacorp. We're just a small bootstrapped company and producing our videos is the most expensive and time-consuming part of our platform. Luckily we still offer some added value besides videos, and make it easy to "do the right thing" and pay a subscription. Yet, we just have to live with piracy I guess. Vimeo didn't prevent it, although perhaps made it only slightly harder.
It looks like the "hack" is to only set the referrer header of the request to be the domain that's whitelisted which can be done with any HTTP client, but the issue is also 4 years old. I wonder if that's been addressed because the referrer header is really not something you can trust from the client.
I wonder if this also means if you use browser extensions that focus on security (such as randomizing your user agent and deleting the referrer header) that those folks wouldn't be able to even watch the videos.
Thanks for bringing this to my attention because if domain restriction does indeed still work like this then I don't think I will use Vimeo for that feature alone.
Signed URLs with both time and IP address based restrictions would be ideal. I wonder if IP address based restrictions is something Mux has planned.
Yes, we come across some people with privacy browser extensions that remove the referrer and indeed this is causing playback issues for them.
It's still a fairly effective protection for casual copying or link sharing, but of course it's easy to circumvent. Even DRM gets broken all the time, so it seems like a bit of a futile effort to try to prevent it completely.
I use a $20/month VPS with unlimited, unmetered 10gbit bandwidth (no, I do not use outrageously priced "public clouds").
I have no troubles serving 4K video (with a 720p low-bitrate transcode) with a simple <video> tag, and I do not pay for bandwidth. This month, I've egressed 11TB for $20, and I could easily triple that at no additional cost.
I can stream 4K without buffering fine and I've never had a user complain, so it works.
The benifit of a cloud/managed cdn is in it's availability, latency, and peering agreements.
Your vps is perfectly fine so long as you're not serving traffic in China, India, etc. If you need to push data globally, need to handle very peaky traffic above the throughput of one machine, or need to have 99.9999% uptime, a cdn will look attractive.
Outsourcing your infrastructure to others is an existential risk. CDNs and such don't look so good to a lot of people because there's something to be said about the nature and value of doing it yourself. The nature being that no one cares about you more than you
An analog for me is car repair. I could take my car in to get oil changes, have brakes serviced, etc. etc. Disregarding the money I save the reason I don't use those services is because those technicians and companies do not care about the quality of their work on my property as much as I do.
As an example, I was feeling too lazy to do a radiator replacement myself and so I took it to a big shop. Terrible mistake, when I got the car back they'd unplugged some of the sparkplug wires and forgot to plug one back in. There's no way they didn't notice the rough idling when moving it out of the bay. Even worse they wanted to say nothing was wrong until I had them pop the hood and pointed out the spark plug boot just sitting there.
Edit: To expand on this, the answer isn't buy a CDN solution. The answer is make CDN solutions so easy to implement that anyone can setup their own with their own hardware hosted in colos around the world.
> To expand on this, the answer isn't buy a CDN solution. The answer is make CDN solutions so easy to implement that anyone can ...
... update their CNAMEs to point at a different company's CDN or a different video serving platform, and wait for the DNS to propagate
To me at least, the risk of a CDN or a video hosting service going bad or pulling your content is mostly the same risk as "colos around the world" going bad or pulling your content. Possibly a lower risk for most people - the chance of Cloudfront/Cloudflare/Akamai or AWS/Azure/GCE going broke or shutting you down is quite a lot lower than the risk of other smaller colo providers and your own hardware going dark. There's probably a smaller gap between smaller CDNs and cloud compute providers compared to rolling your own - but for most use cases I'd guess having a "cloud agnostic' design and ability to switch compute and CDN resources quickly and easily is a lower effort and more reliable way to reduce existential risk to your business.
I'm sure there are businesses who's risk estimates don't match mine - Darknet Markets for sure, probably "adult content" as well (given the observed puritanical zeal some of that industry gets deplatformed with). But for most clients and projects I've worked on in the 15-ish years since "Cloud services" became mainstream, owning hardware and leasing colo space would have been a totally misplaced cost/risk optimisation.(And I say that as someone wo used to do 2 or 3 trips a year from Sydney to colo facilities in the US and the UK with my luggage filled up with pre-loaded harddrives and toolkits to screw them into servers we owned on both US coasts and in London. I kinda miss the travel a bit, but I _totally_ prefer being able to get my phone out and provision new cloud "hardware" instead of hoping i had enough hot spare capacity somewhere, and ordering new hardware and plane tickets to fix disasters...)
Outsourcing your infrastructure to others is an existential risk, no doubt, but virtually all of us do it in our personal lives -- we trust that electricity will be delivered to the plug and water to the faucet, and would die off in quite short order if it did not.
Building your own infrastructure is like living "off the grid" with a wind turbine and a well and a composting toilet. You might have mitigated some risks but let's not pretend that there isn't an enormous cost in doing so.
>Building your own infrastructure is like living "off the grid" with a wind turbine and a well and a composting toilet.
And your infrastructure still isn't really literally "off the grid" of course. It's dependent on colos, network providers, etc. Sure, there's far, far less of a single point of failure than using YouTube but you're always going to be dependent on others to some degree.
Further, no one has the time or the money to do everything ourselves. To the upstream comment, I have neither the time or the energy to take on car maintenance. I have other things to do even if it means I spend more money and sometimes the shop doesn't do an optimum job. I'm not going to criticize someone who wants to do things themselves, but you have to choose.
So I can’t write a huge comment now because I am on mobile. What’s very ironic and hilarious is that after reading your comment the power in my section of the city has gone out...
Sorry but this absolute nonsense. In reality nobody does care how you host your website snd files, the only thing users care for is the content is always available and fast.
> Outsourcing your infrastructure to others is an existential risk.
FYI:
"An existential risk is any risk that has the potential to eliminate all of humanity or, at the very least, kill large swaths of the global population, leaving the survivors without sufficient means to rebuild society to current standards of living."
No single CDN will give you 100% uptime but, for video serving, you can use multiple mirrors across multiple CDNs. In html5 you can provide multiple source urls for the same content.
Of course that depends on your users too. You have one connection point to the wider Internet and differing peering arrangements might many some (or possibly many) can't access your resources that fast even if you can serve them that fast as far as your provider's egress points.
Those outrageously priced public clouds and CDNs likely have greater global peering arrangements that will vastly best a cheap VPS for a lot of uses. They also offer availability guarantees, bandwidth guarantees that a cheap VPS will never offer (that 10gbit bandwidth will be "up to" on a shared pipe), and other potentially significant considerations.
> I've never had a user complain, so it works.
Of course if all your users are in topologically convenient locations so they can pull content from that one VPS at a good rate, you don't see sufficient concurrent access (or don't at times other users of the providers' bandwidth are) such that the lack of bandwidth guarantees are not an issue, then you do have the right tool for your job. But this is far from a one-size-fits-all business.
(though of course if a user just goes elsewhere without complaining, how would you know?)
I was able to get a custom 10gbit unmetered plan from Virmach a couple years ago. Definitely real, and I've been pulling double-digit-TB egress for months without issue.
I see on their website you can upgrade to 10gbit metered for an extra $2/month but I don't know what they'd charge for the unmetered options now.
There are lots and lots of providers if you are happy with 1gbit unmetered though: I'm a happy customer of BuyVM (starting from less than $2 a month!) and Scaleway (bandwidth depends on your plan).
If you are happy to spend a bit more for your own dedicated box, OVH, Hertzner, Online.net are great options. All of them offer unmetered BW I believe.
unfortunately after doing research into all of those, their terms of service allows them to charge more or cancel your account after what they consider to be 'excessive' bandwidth usage, so i wouldnt consider them truly unlimited or unmetered. It doesnt seem virmach offers unmetered anymore, but I may reach out to them
I asked Hetzner specifically whether they'd have a problem if I saturated my dedicated Gb connection for a month, and they said no, it's mine to saturate.
I don't remember if this is on a dedicated box or a VPS, but IIRC it was dedicated and the VPS has a 3 TB/mo limit.
Hosts such as Leaseweb, nForce or Worldstream have 100TB+ plans you can purchase. If you're willing to spend quite a bit, they also offer truly unmetered plans. I've personally used all three of them, but never used more than 100TB a month.
I have a dedicated 25 EUR/month server from Hetzner that is used for serving video content.
It's a pretty good solution, but not perfect. I have heard that some people have trouble watching content, most likely due to peering between Germany and the US.
There's no transcoding options for the end-users since I'm already hosting 1 TB of content and there's not really room to keep different versions. Mostly not a big deal for my users but it's probably not helping with the connectivity issues.
I've considered other options but there's really nothing that can beat this setup when it comes to price performance. Serving a terabyte of content for 25 euro a month is pretty unbeatable. I recently had a 24 hours period where the server pushed out like 1.06 TB of traffic. This kind of bandwidth would be killing my wallet otherwise. And since this is a non-profit project, I'm eating all of the costs.
First of all,you can use HTML video element and host the video yourself. (This works in non-js browsers too. You can enhance it by video js scripts though for js enabled browsers.).
I think that peertube will be another good option. You can self host it and there are also many available public instances of it. This is particularly useful if your userbase is very large because it uses Bittorrent(webtorrent) p2p to reduce load on servers and it increases availability of content if viewerbase is huge.
Well you can't be average to run a good peertube instance. I was thinking more of people like Joe Rogan and Linus Tech Tips. People who've built a company around their content creation hobby and are capable of paying for ops and potentially seed boxes if needed.
It wouldn't be hard to host, but you'd have to be confident in your service provider or consultant.
Of course I doubt Linus would ever be censored by Youtube, he was just an example.
Every time I access Vimeo, with no exceptions, I'm forced to solve a recaptcha v2, then expected to wait for longer than 30 seconds before being allowed in.
Result: I don't use Vimeo.
Any alternative is better.
I don't have this problem with any other website (that I have noticed), including any video and streaming services.
It works without the VPN, but I need the VPN more than I need Vimeo, so I just avoid anything that uses their service to host videos.
They seem to be very aggressive blocking IPs. For example, I have VPS on Digital Ocean which I use for small projects and also as a VPN server. The IP has been "mine" for almost a year, I don't use it to scrap sites or abuse any service... but I still get the damn captcha on their videos.
That's why. Many providers can detect a VPN hosted on DigitalOcean and trigger security measures or captchas. I'm testing a commercial vpn (Mullvad) this month and it's working fine.
This is a nice write up, but don't forget that YouTube isn't just about hosting. It's about distribution. If you host your own videos, you are 100% relying on your own means of getting people to watch it. In the use-case that is state here, that's probably just what the author ordered. But not everyone has that luxury.
Does anyone have a source for the claim that it saves a lot of bandwidth, actual figures? The only PeerTube videos I’ve ever looked at are saving absolutely nothing, because it’s only the original server seeding it. Admittedly they haven’t been hot-off-the-press videos that are getting a large number of views immediately, which is the main time when you may have more seeders, as I understand it.
It's probably less about having peers seed videos all the time but buffering bandwidth spikes.
Let's say a video gets posted and gets a million views in the first day. That's a lot of load on a server. But if thousands of peers can serve each other the chunks, then the server isn't responsible for all of them.
So WebTorrent can provide a level of scalability without greater hardware. Just doesn't mean that most of the videos are going to be served by peers.
Webtorrent was just added to libtorrent, so hopefully it will be coming to standard torrent clients soon. I'm hoping this will lead to more seeders and wider adoption of webtorrent.
There is also the problem of seeding from battery-powered mobile devices being impractical. Hopefully that can be worked around somehow.
If you're at the point of spinning up your own CDN and such, it doesn't seem like it'd be too rough to run your own peertube instance if you have enough of a fan base...
Why are people overcomplicating web video so much?
With the HTML5 video tag it's not much more complicated than serving an an <img>. You still "need" two formats, I know that sucks (but av1 will hopefully become the solution). A small to medium sized blog can just upload the files to shared hosting (or even archive.org if space is sparse). No JS, no CDN needed.
If you want your content to be accessible for most people you also need to transcode your video to several resolutions. This coupled with an adaptive bitrate player [0][1] will allow clients to choose the resolution they can afford (so that people with different bandwidth can access your content)
When dealing with more than 10s or 100s concurrent viewers the required bandwidth on your server will be high and putting a CDN in front may be required.
It depends on your market. If you're aiming for people at home in Seoul, yeah that's probably alright. Their connection should be great and stable. If you're aiming at people transiting in Mumbai and watching stuff on their phone in the local train, 720p won't do.
I was referring to (small and medium sized) personal blogs and websites (like the one in this post), i.e. not a digital commodity on a market. If you're out there to make money I realize you have to be more fancy with what you put out there.
Great question, it's actually not quite that simple. HTML5 was indeed supposed to bring trivial video to the browser, and it almost did.
If you want a good video streaming experience for all your viewers, you need something called Adaptive Bitrate (ABR). Some protocols that you may have heard of the implement ABR include HTTP Live Streaming (HLS) and MPEG Dynamic Adaptive streaming over HTTP (DASH).
ABR allows the stream to adapt to the bandwidth capabilities of the viewer. If you don't do this, some users will experience buffering, and some will have to sacrifice on quality.
Unfortunately most browsers don't support an ABR format natively, so you need to use Media Source Extensions, and a more complex player to support these protocols in a browser.
Well, I don't know about you, but sometimes I'm on a 3G network. Yes, I could wait to get home. But some people also have really terribly bad providers offering them very little bandwidth.
So, by doing this, you make sure your content can reach more people. Which, to me, seems to be the whole point of making and putting it online in the first place
Of course, but there are instances of the opposite. I encounter both from time to time. For example I want to show someone a video while having a drink, usually it doesn't have to be crisp 4K 60fps, just play the god damn thing before we lose interest. Other times I want to watch a video, I'm in the middle of nowhere anyway, I have time and data in the monthly cap, just not enough bandwidth.
User choice and smart defaults would go a long way.
Well, people do expect YT/NF level. And sadly we've trained everyone to expect that everything starts playing instantly.
So if your income depends on people not rage-quitting your page, you'll have to provide something that satisfies their "needs", or more appropriately "desires".
I'm not saying people shouldn't do more for user experience, but the cost-benefit seems to be bimodal. Do the minimum, or pay YT/NF/Vimeo (or CF or AWS Streaming, or get ready to bankroll your own).
It is by no means a clean or modern solution (I agree, go with Youtube etc or provide a transcoding js player), but about a couple decades ago many sites would simply link to several resolutions of a video, allowing the user to play either a low, medium or high res version as per their current data connection. So that is one option that sidesteps adaptive bitrate players as well as a large CDN.
As has been pointed out above, having some kinds of video downrated to be streamable on 2G isn't much different from not having the content at all. While 4K is rarely required, pushing out coding tutorials at any resolution below 1080p is nearly worthless, and pushing it out at 480p is worthless (Unless it's a retro C64 BASIC tutorial in which case rock on).
Work... Yes, you can watch a video fluently, but it takes (on Desktop, Firefox, with Throttling on "Good 2G") maybe ~2min to load the video page. However, you can start watching the video before the full page is even loaded.
You can probably implement a dumb version of this where transcode a few different versions with ffmpeg (which is amazing, but takes some tinkering), use browser API's to guess the right one as a default, and give the user control if they'd like to switch.
I'd still try HLS but this may be good enough for v1, depending on what you're building.
Around the 1:14 mark he goes into why you can't just use the html video tag. It was one of the best explanations I've heard around HLS and what it takes to stream video efficiently.
It's easy if you want to serve the video as it is but usually that's not what you want.
I have Plex (like a self hosted Netflix) on my home-server and some other people are also using it and on many different devices and connection speeds. It has to transcode the video on the fly and cache it depending on the client to have a good experience. You can't just serve 4k video to everyone.
My usecase involves sharing private video with access control for my sports club. For that I use https://mux.com/ which take care of hosting, CDN and all the conversion shenanigans. On top of that I've build a Django app which uses video.js as a player.
Quote:"So that's how I moved off Vimeo and started hosting my video content myself"
No, no and no. You still don't host your video content yourself. You simply found another cheaper service and despite your claim this isn't some paid ad (quote: "This really isn't any sort of paid or sponsored content crap for Bunny."), it's exactly that.
> despite your claim this isn't some paid ad (quote: "This really isn't any sort of paid or sponsored content crap for Bunny."), it's exactly that.
I don't understand this comment. Do you have some sort of proof that the CDN reached out to the author, or even knows he exists outside of a CMS?
I've seen this sentimentality a lot, where people aren't allowed to talk about a service or a product positively without some sort of money being involved or sneaky guy-in-a-trenchcoat bs. I really don't understand it.
Whether they're paying someone else for infrastructure is hardly remarkable. Almost no one is completely off the grid. (Do you have your own power substation?) The author controls his own namespace, so he can swap it out any time and do so seamlessly. Contrast to Vimeo or YouTube where you have no control at this level.
He seems to be using them as a CDN, not to host the video files. There's no reason for this not to work without a CDN (I do it on one of my sites, where a CDN isn't really needed).
Regarding Bunny, it may be a paid ad, but they do have very cheap prices. CDNs starting at 0.005/GB with pops in NA, Europe, and Asia are hard to find.
Can you still say that you are hosting the content yourself if the content is still on a 3rd party CDN? I guess that is just semantics. Great article none the less!
> [...] I still store my large app downloads and videos on S3 and then have Bunny (and previously MaxCDN) pull from AWS as an origin server. [...]
He hosts the videos on S3, the CDN fetches the files from S3 and caches it. He's using the CDN for the cheap traffic/more pops. This would work without S3 and without a CDN too.
It won't work on all devices, but a h264 video encoded with the baseline profile should play fine on any phone or tablet sold in the past 5 years (maybe even older). On desktop, assuming the browser supports HTML5, it should be fine too.
Just to be sure, offer at least one version of the video with VP8 just to cover weird cases where h264 isn't supported. You can also encode 480p, 720p, and 1080p versions for users on slow connections.
Now, will it load on the original iPhone or IE 6? Maybe not - they'll see a link to the video file instead of a player - but not everyone needs to support legacy devices and browsers.
YouTube, Vimeo, and other similar services are nice because they handle everything for you, but sometimes they become too expensive or are blocked. Depending on the type of user you have, <video> with a h264 video is cheaper and works well enough.
Mozilla recommends[0] WebM (VP8 and Opus) and MP4 (h264 and AAC) for good compatibility. That's why I suggested suggested having a VP8 version of the video for cases like this.
I guess OGV could be used for even better support, but it doesn't compress as well.
I've been thinking about a "meta cloud" stack - essentially something with the convenient interfaces of various common SAS but then backed up by a user configurable transport.
So you could "migrate" existing apps to say, use some machine at a colo instead of a variety of s3 services without much effort and thus unshackle yourself from a vendor.
Maybe you are making gobs of money and don't care, but a lot of people aren't and saving, say, a few hundred a year sounds very tempting. Not every competent person is rich
What is all of this technical jargon? This is not the solution at all.
If it's equally hard and an equivalent amount of effort than starting from scratch then it's completely a non solution. It's just another giant mountain to climb.
I'm looking more into it. It looks very complex and sophisticated. It's also built on a cloud "marketplace" where you're still doing SAS, now just in a way more complicated way with some wonky exchange system like you're a municipal energy broker.
Apparently they even sell multi-tier training sessions to understand all the jargon and complexities. There's no pretense that it takes anything less than months or years of study to use the thing
No, this is not it at all.
I'm talking about a worry free, drop in, simple replacement, an hour max. Set it, forget it, walk away. Not a multi year career path.
I swapped out s3 with simply doing scp and holding the same interface. It worked fine.
Does it scale to a 100 million users? No of course not. The point isn't to provide giant scale solutions over multiple continents but something to replace a ~$20/month service that a few hundred people use and make it effectively $0.
There's a huge market for that and it's the vast majority of cloud software written.
People will defend these complexities as The Right and Proper Way except it isn't. I've built half a dozen companies for people using $10-$40/month VPSs that do 6-7 digit annual revenue and run for years. All this autoscaling kubernetes prometheus blah blah blah, totally unnecessary. We aren't serving terabytes per second of video here... Transactional RDBMS, a Crud interface, basic file store, done and done.
The problem is all these systems are designed to facilitate building the next Paris or Hong Kong and if you're just trying to build the equivalent to a store on the side of the road, you have to do it the Paris way. It's nonsense.
People have other things to do with their lives than spend vast amount of time keeping up with the latest versions of irrelevant stuff to solve problems they will never have.
Imagine if HTTP was truly distributed and servers from different organizations could pool their bandwidth to serve static content. Similar to Bit Torrent.
CDNs are the best thing since sliced bread. Found this out both from ease of setting up frontends and the pain of setting up backends.
I wonder if there's a way to build a database on top of a CDN, or a webapp backend (might just be something like serverless, but instead of function definitions you have files+config a CDN automatically knows how to run). Something like Plan9 for the web.
This is very helpful for anyone trying to understand how to avoid using YouTube or Vimeo. Many people find those choices fine, but many of us find them unacceptable for a variety of reasons.
While the author's answer may not be perfect or precisely tailored to your situation, they cover all the bases IMHO. A must read.
And several of the comments add to the discussion.
If the author is concerned about bandwidth costs, it sounds counterproductive to encode the videos as 60fps where 30 is plenty for everything but high speed action shots. Given that it sounds like he is doing demo videos / screencasts etc, it there is a lot to gain here in just getting the encoding settings right.
The best homegrown platform I have seen so far is https://media.ccc.de/ , where the video and audio files from Chaos Computer Club events are stored. I don't know how willing they are to share the code though.
This is interesting but I’d have to assume that the actual cost Vimeo is charging is not an important factor here. The developer time spent setting this up would quickly exceed the annual fee for Vimeo in just an afternoon. That excludes the ongoing maintenance and inevitable edge cases you would encounter over time. Still fun, but I don’t think Vimeo’s price justifies this effort alone.
time=money assumes you are taking time away from something else, if there is no other work to be done that generates money then spending some time to save a little money might be a valuable way to spend time.
Most likely it's just to satisfy some sort of nerd-ocd.
They suspend accounts (after months if not immediately) that abuse serving disproportionate amount of non-HTML content, videos specifically. However there is still ambiguity (or lack of detail) in their terms if you can use their Workers, a paid FaaS, to stream blob data.
They do cache small video files, even for free, but I think they don't want you to run a streaming business on top of them (without using their dedicated service).
for non commercial use I have used github to host my website for a long time, and I have had some instructional videos on there. For small purposes like this, or maybe how-tos on open source software, I can't see github having a problem with or noticing the bandwidth
The issue is that a CDN is still involved - and they, like YouTube and others, can ultimately choose to deplatform you. LBRY (decentralized video sharing) might be a better alternative, perhaps? https://itsfoss.com/lbry/
Sure. "All the time" across Youtube's userbase of people who can make enough social media noise that we hear about it (so probably an order of magnitude more often than all the cases we hear about, but still very rarely for any one individual business or person.
If a client or project's content is mainly intended to be viewed and/or discoverable via the project website, I'm happy enough to have a plan along the lines of "We'll publish/host the video on Youtube (under an account that's exclusively for it and definitely not in any way linkable to any important Adworfds, gSuite, or Android dev accounts), and if the shit hits that fan there and they shut it down, we'll make sure we can reupload the videos to Vimeo or DACast or S3/Cloudfront or wherever, and just flip the video.example.com CNAME to match."
If you're relying on Youtube/Vimeo/Instagram/whatever for _discovery_, then you've got a totally different problem. (And, as far as I can tell, one without any good mitigation strategy. If you build all your brandvalue in a youTube channel, you're totally at the mercy of shitty cotent monitoring algorithms, automated copyright or DMCA takedowns, and 4Chan brigade attacks...)
Youtube is owned by Google. The parent comment to you was talking about using decentralized solutions to avoid takedowns on CDNs and platforms like Youtube.. which they explicitly mentioned.
I would highly suggest keeping the same CDN as the cloud/storage offering you work within. You get dinged quite a bit on transfer costs otherwise. So, if you're on AWS, stick to Cloudfront, etc.
Potentially relevant to post:
Note: I am the founder of Loom, so this is obviously extremely biased.
With Loom (https://www.loom.com) you will soon be able to upload unlimited videos (as well as record since we have recorders) to a plan for $10/month. No caps on viewing or storage.
This manifests as buffering on slower connections, where YouTube or Vimeo would just downgrade the user to a lower bitrate transparently (or nearly transparently).
An end user today will expect that behavior and have very little tolerance for buffering if their connection is unable to smoothly play the one bitrate the creator published (no matter how fast the CDN is).
Edit: I’m aware that it’s possible to do adaptive bitrate streaming outside of using Vimeo or YouTube (as several commenters have explained below) however this isn’t what TFA describes and I think it’s important to note this deficiency in the author’s described approach to serving their own video.