6 ms·

If you don't need PPV (pay per view) or fancy monetization, you can just put them on Vimeo or even YouTube for very cheap. Or CloudFlare Stream, maybe: https:/

If you don't need PPV (pay per view) or fancy monetization, you can just put them on Vimeo or even YouTube for very cheap. Or CloudFlare Stream, maybe: https://www.cloudflare.com/products/cloudflare-stream/ https://www.cloudflare.com/products/cloudflare-stream/ Edit to add: Please, for the love of god, do not self-host your video as a static file. There is a LOT of thought that goes into modern video streaming, such as on-the-fly transcoding to different resolutions & bitrates, pre-caching the next few seconds, seeking support, thumbnails, auto-captions, hardware decoder support... absolutely none of that is trivial to implement, but they make a huge difference in end-user UX. You may design your video on some sort of 5k supermac, but a lot of your viewers will be watching them on cheap Androids. The video providers spend a lot of time optimizing their streams and networks for such use cases. You will not, and your users will suffer for it, if you try to self-host. Please, please don't do this. Signed, that guy who hates it when you're expected to download a 50 meg MP4 to understand a product.

rahimnathwani 5y ago
"The video providers spend a lot of time optimizing their streams and networks for such use cases. You will not, and your users will suffer for it, if you try to self-host. Please, please don't do this." If I follow these steps, what would I do wrong that would negatively affect my users: 1. Google 'ffmpeg hls nginx' 2. Encode my video at a bunch of different resolutions and bitrates. 3. Rent a server at hetzner or wherever. 4. Install nginx and do the minimal configuration needed to serve the files I prepared. What could go wrong that would allow the video to play on a fast connection, but not on a slow connection (or slow device)?
- technobabbler 5y ago
  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.
  - rahimnathwani 5y ago
    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.
    - technobabbler 5y ago
      > 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).
      - rahimnathwani 5y ago
        Do you count certbot as self-managing HTTPS?
        technobabbler 5y ago
        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?
iainctduncan 5y ago
CloudFlare is looking like it's serving the right market point. If anyone has alternatives to suggest in the same vein, I'm all ears!
- technobabbler 5y ago
  It's important to note that Cloudflare charges by the minutes served ($1/1000 min). If your video is a short looping background or product teaser, it's probably affordable. But if you're streaming entire demos or movies or such, it can get expensive pretty quick. Vimeo is a flat $20/mo, subject to fair use (approx 2 TB/mo). Worth doing the math to see which makes more sense for you.
  - iainctduncan 5y ago
    that would seem to be a reason to build an app that can easily have vimeo swapped out for cloudflare when you reach liftoff, eh?
  - iainctduncan 5y ago
    thanks, that's a very helpful tip. Is there any disadvantage to Vimeo pro against cloudflare that you think is worth noting?
    - technobabbler 5y ago
      I don't know your exact use case. If you tell us more, we can help you better. We used Vimeo to serve an approx 30 sec video to about a million viewers a month and it was great. We noticed some minor downtime (few minutes at a time) but that was acceptable to us. Cloudflare might be more reliable, not sure? Network infra is their bread and butter, and I tremendously admire them, but their streaming offering was overkill for our basic needs. Ultimately their target markets are different. Cloudflare is an infrastructure company targeting devops teams, Vimeo targets small-to-medium content-driven businesses who don't want to do devops. Probably Vimeo's control panel is easier to use for content producers, whereas Cloudflare might have better APIs for devops types? At a few thousand viewers a month, it's a pretty trivial use case and either company (or any other professional video host) would probably be just fine. It comes down to your own pipeline/production or business needs, probably. As for being able to switch from one host to another, hopefully you're promoting a landing page of some sort and not a direct video URL. In that case you should be able to switch video providers at any time without interruption. Just keep the old version up alongside the new one for a few days, in case anyone has the page cached.

rahimnathwani 5y ago

"The video providers spend a lot of time optimizing their streams and networks for such use cases. You will not, and your users will suffer for it, if you try to self-host. Please, please don't do this." If I follow these steps, what would I do wrong that would negatively affect my users: 1. Google 'ffmpeg hls nginx' 2. Encode my video at a bunch of different resolutions and bitrates. 3. Rent a server at hetzner or wherever. 4. Install nginx and do the minimal configuration needed to serve the files I prepared. What could go wrong that would allow the video to play on a fast connection, but not on a slow connection (or slow device)?

technobabbler 5y ago
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.
- rahimnathwani 5y ago
  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.
  - technobabbler 5y ago
    > 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).
    - rahimnathwani 5y ago
      Do you count certbot as self-managing HTTPS?
      - technobabbler 5y ago
        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?

iainctduncan 5y ago

CloudFlare is looking like it's serving the right market point. If anyone has alternatives to suggest in the same vein, I'm all ears!

technobabbler 5y ago
It's important to note that Cloudflare charges by the minutes served ($1/1000 min). If your video is a short looping background or product teaser, it's probably affordable. But if you're streaming entire demos or movies or such, it can get expensive pretty quick. Vimeo is a flat $20/mo, subject to fair use (approx 2 TB/mo). Worth doing the math to see which makes more sense for you.
- iainctduncan 5y ago
  that would seem to be a reason to build an app that can easily have vimeo swapped out for cloudflare when you reach liftoff, eh?
- iainctduncan 5y ago
  thanks, that's a very helpful tip. Is there any disadvantage to Vimeo pro against cloudflare that you think is worth noting?
  - technobabbler 5y ago
    I don't know your exact use case. If you tell us more, we can help you better. We used Vimeo to serve an approx 30 sec video to about a million viewers a month and it was great. We noticed some minor downtime (few minutes at a time) but that was acceptable to us. Cloudflare might be more reliable, not sure? Network infra is their bread and butter, and I tremendously admire them, but their streaming offering was overkill for our basic needs. Ultimately their target markets are different. Cloudflare is an infrastructure company targeting devops teams, Vimeo targets small-to-medium content-driven businesses who don't want to do devops. Probably Vimeo's control panel is easier to use for content producers, whereas Cloudflare might have better APIs for devops types? At a few thousand viewers a month, it's a pretty trivial use case and either company (or any other professional video host) would probably be just fine. It comes down to your own pipeline/production or business needs, probably. As for being able to switch from one host to another, hopefully you're promoting a landing page of some sort and not a direct video URL. In that case you should be able to switch video providers at any time without interruption. Just keep the old version up alongside the new one for a few days, in case anyone has the page cached.