Video startup times are kept low in modern clients by starting at low bitrates and then seamless adaptation up. This is very important for advertising companies, social media, live streams, etc. Every second of startup time cost massive user loss in live streaming (this is well researched and documented). Additionally streaming protocols (HLS/DASH) force files to be encoded such that a full download is not required for a decode to happen. This is not a requirement (and pretty rare unless you know what you are doing with an encoder) for file based workflows.

Fast forward for low power clients relies on an "iframe only" track as there decoders can't do many x realtime decode. This is not present in modern file based work flows.

Seeks use the same startup/segmentation requirements as video startup.

Thumbnail scrubbing requires a thumbnail track and is not supported by file based workflows at all.

Clip previews on sites load at low resolution/bitrates and can be poped up to "full resolution" via ABR. Doing a preview of 10x 4k streams without abr wouldn't work even on a modern gaming rig.

I'd love to hear how you'd do SSAI on top of a file based workflow.

You could of course build a "file based" implementation that had all of these features, but you would just be rebuilding DASH or HLS.

  I'd love to hear how you'd do SSAI
  on top of a file based workflow.

Given that this is a discussion of Netflix and Bittorrent, and the popularity of ad blockers among HN readers, I think the answer to "How would you do server-side ad insertion" is "I would accept losing that feature"

Popular video file players have supported generating iframe tracks for fast forwarding and thumbnail scrubbing for many years now, is there something about the way eg MPCBE and PotPlayer operate that is somehow unreasonable?

It's terrible performance on a power limited devices. It either burns up your battery or is unreasonably slow. Particularly when the source stream is high resolution or complexity.

Sure, but if you have the file, you could generate these ahead of time on a more powerful machine.

At any rate, I don't think users would balk at being given a choice.

> You could of course build a "file based" implementation that had all of these features, but you would just be rebuilding DASH or HLS.

Yeah, but would they pay for it?

HLS and DASH, or any other protocol along their lines (like what youtube used long ago for own HTTP streaming) are still completely inferior to proper streaming protocol on latency and such. I'd say plain "seeking over http" with range requests does often work with lower latency than best HLS/DASH servers on SSDs.

A proper udp based streaming of course tears HLS to pieces

HLS was just a stopgap so providers could use cheap http cdn's.

It worked well enough nobody can be bothered with real streaming now...

SSAI - you write your own player and do it that way?

Also most streaming services offer an offline playback option today.