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?
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.