Reputation: 2465
Is there an advantage of serving static video content (not a live stream) via adaptive streaming protocols such as HLS or DASH over serving them directly as files using HTTP server in terms of speed?
Example case is when you have a 500MB mp4 h264+AAC video that you have to serve on a website via HTML5 video element. Would you rather serve it directly, since most popular browsers implement functions such as seek without downloading the whole file first; or would you rather use ffmpeg or similar solution to create HLS chunks from the mp4 file and instead provide .m3u8 playlist source to the HTML5 video element. Is there a real advantage in terms of speed of doing this?
Which one would you implement if you had hundreds of video files all served as static content?
Upvotes: 2
Views: 1544
Reputation: 25491
Most large Video on Demand (VOD) OTT services will use ABR for streaming.
This is because it allows the end user device choose the best resolution and bit rate depending on the current network conditions.
It can also avoid wasting bandwidth as the device will be aware of its own capabilities and can avoid, for example, streaming 4K if it can only display HD or lower.
It can help speed of start up, by using a lower resolution and bit rate, when a video first starts as this will download falser and then stepping up if the network conditions allow. You can often observe this on services like Netflix and YouTube when you start a new video.
You can see ways to view the stats and the switching behaviour here: https://stackoverflow.com/a/42365034/334402
If you have a closed user group and you know they will all have high speed connectivity to your server, for example on a high capacity internal network, then you may not need the complexity, but in most other cases ABR is usually favoured.
Upvotes: 6