Comment by technobabbler | Hacker News Reader

Comment by technobabbler | Hacker News Reader

Parent Full thread

None of this is impossible to do, just a lot more work than clicking "upload" on Vimeo and letting it take care of there rest for you, for what, $20 a month? Those 4 steps are already work that most won't bother to do. Because why? What would the advantage be?

Things that could go wrong: The end-user's frontend (a 4-year-old phone browser, a crappy smart TV, a Chromecast, Microsoft's browser abortions, whatever) has to support your protocol of choice. HLS is more and more common but it's not a guarantee, whereas the Vimeo and YouTube players have years of legacy and fallback support and have their CDNs pretty stabilized. With HLS you might still need a frontend JS player and then have to manage the distribution and packaging for that. And if you care about the video player UX, things like supporting user-chosen resolutions (overriding network speed), theater mode or easy full-screen or subtitles, 1.5x+ speed, etc. And you have to invalidate and re-CDN a bunch of separate files every time your source file updates.

But really, again, it's not that you CAN'T recreate what Vimeo and YouTube etc. have done, but why would you want to? It's a lot of effort to end up with an inferior UX, higher bandwidth charges, and a whole new pipeline (if not stack) that you have to maintain. No reason to reinvent the wheel for such a common use case.

Edit: And you STILL have to CDN it in the end, unless you have the phattest pipes in all the worlds. So you still have to subcontract with a third party in the end. Why not just put it there to begin with? It's silly.

It's one thing if you're Google-scale and need to in-house everything because you're dealing with a billion viewers a day, but when it's just a few thousand (the OP said that in a different comment), it's really not worth your time or bandwidth charges to reinvent that infrastructure.

FWIW I use Vimeo, and do not choose to self-host videos.

But users wouldn't 'suffer' if I did self-host. They might not be able to play at double speed or whatever, but they'll still be able to play the file, even on an old device with a poor internet connection.

Some people have ideological reasons for wanting to self-host, and I wouldn't want to discourage them unnecessarily.

> Some people have ideological reasons for wanting to self-host, and I wouldn't want to discourage them unnecessarily.

Off the top of my mind, there are only two web things I would strongly discourage people from self-managing whenever possible... video and HTTPS. Of course both are doable, and might be fun as a learning experience or a matter of ideological purity... but otherwise, their ROI is so, SO low it's not worth it (as in, you'll spend way more time and money fixing things than you would ever save having a pro do it).

Do you count certbot as self-managing HTTPS?

Personally, yes? I'd had it silently fail for a few weeks (I misconfigured the expiration alerts somewhere, or maybe the mailer daemon wasn't set up right on that particular vhost, or some package it relied on failed, and it couldn't renew for several weeks but I didn't hear about it until the cert expired and the page failed). On more than one occasion it was an issue.

And when you need wildcards, it gets even more complicated.

Obviously I'm not a very good sysadmin, but that's the point... I don't want to be and don't need to be, not when someone else can do it better and faster.

It's not an ideological thing, just a personal preference for making user-facing features as opposed to tinkering with the backend. Some people enjoy that sort of work. But users don't see it or care about it unless it breaks, which it often does in my experience as a mediocre full-stack dev with increasingly front-end leanings.

Edit: And on newer-generation serverless/Jamstack hosts (Cloudflare, Vercel, Netlify, etc.) you might never even get a shell to tinker with Certbot on. Which is arguably a good thing, especially compared to the bad old days of having to quadruple-configure HTTPS across your CDN, Varnish, Nginx/Apache, Certbot, and maybe cPanel or similar too. Yikes. Every single part of the intermediary chain was prone to frequent breakage. HTTPS these days isn't for authentication anyway, just for preventing drive-by MITM. Even EV certs aren't a good guarantee. So why do it yourself?

That's an understandable perspective. But if someone can't reliably self-host HTTPS with certbot, I'd advise them not to self-host anything, as they likely don't have sufficient sysadmin skill to keep their servers safe.

Just use Heroku, Netlify etc.

Yeah, exactly. I am so grateful hosts like that exist :)

Apart from robust anti-download protections, I could do pretty much everything I needed using ffmpeg (compiled with a customized configuration), video.js running a handful of custom plugins and some other pieces of open source software.

Simple cryptography was possible, although I didn't use it.

The only thing I really needed to hire was a CDN.

That way I didn't step anywhere near of a vendor lock-in trap, had a high degree of control over my platform and could even develop some on-premises customizations that would be simply impossible had I relied on third-party, internet-only solutions.

So I don't know. Of course I wouldn't reach the scale of yt or vimeo (and I didn't intend that anyway at all), but I guess the things you are talking about are not as hard to do as you think.

> The only thing I really needed to hire was a CDN.

Unless somebody was bookmarking your video directly (does that really happen, as opposed to a HTML page / app), this IS what the video hosts offer, just at a higher level. Vimeo isn't a social video platform the way YouTube is, it's just a video host for the most part, including whitelabeling options. What is the vendor lock-in concern?

At the last educational place I worked for, we hosted our videos on YouTube, Vimeo, our own host, and a few other places. Nobody ever knew or asked which was which, except the YT and Vimeo videos were smoother experiences. They were all whitelabeled or else unlabeled.

I'd argue that for most content producers and users, YouTube (for the social network and the wide compatibility across devices) and Vimeo (for the ridiculously cheap pricing and ease of use) are the best choices AS CDNs. Both offer superior developer/producer experiences than a self-hosted stack too.

> had a high degree of control over my platform and could even develop some on-premises customizations that would be simply impossible had I relied on third-party, internet-only solutions.

But I'd love to hear about these cases. What justifies that complexity for you?

I don't understand where you see complexity here. That was a fairly simple setup actually.

About the use cases and motivations, some of the drivers were commercial -- e.g. clients with content they considered too sensitive to be hosted off-premises; clients distributing content to places with limited connectivity; also, integration with custom access control systems.

The list goes on.

> I could do pretty much everything I needed using ffmpeg (compiled with a customized configuration), video.js running a handful of custom plugins and some other pieces of open source software.

This. That's so many points separate points of failure, and doesn't that mean you have to get a dev involved (or have an in-house automated video pipeline) anytime someone wants to post or update a video? Maybe we just have different thresholds of "complexity". I try to keep clients away from unnecessarily bespoke tools, and keep them on simple GUIs supported by proper vendors... but that's just in my sphere of work. In bigger teams it might make sense to in-house more stuff.

Reply on news.ycombinator.com