Dynamic bitrate is the main one - the browser & server coordinate to figure out the highest video quality the user can watch without stuttering/buffering.

The client can do that 100% client side, you can serve pure static files with a JS player that handles the streaming. All you have to do is chunk the video into small 2-5 second chunks at a variety of nitrates and list them all in an .m3u8 playlist file if the right format.

I know because I explored this for a hobby project of a movie I liked. See here: http://lelandbatey.com/projects/REDLINE-intro/

Use your network inspector to observe your browser requesting the individual chunks over time. Note that my server is just an Apache2 file server.

Pretty cool!

always wondered how this handles prebuffering. (i.e. max-prebuffer = chunk-size) ?

> any reasonable browser can play off a HTTP stream

most video players also support http and there is no problem with just putting files up.

imho all the streaming tech, drm, hls, adaptive bitrate selection and whatnot, are just commercial fads to increase margin

Adaptive bitrate selection seems important if your clients have narrow or unstable bandwidth (e.g. mobile), or when you may get constrained by outgoing bandwidth (/. effect aka HN crowd).

imo this is mainly due to the constraint of keeping clientside pre-buffering as low as possible.

sending the whole file at network-speed usually works fine, but maybe uneconomical at scale especially if coupled with users that skip a lot and tend to not watch the whole thing anyway.