I am comparing HLS with other HTTP-based streaming formats - DASH and SmoothStreaming. They definitely have their issues (DASH in particular is the epitome of the second system syndrome) but they fix the two most glaring issues with HLS: separate manifests and non-aligned segments.
Source: I write an HTTP streaming client library for a living.
Separate manifests and non aligned segments have a real impact on the ability of the client to switch qualities in responsabilità to bandwith change, and this to avoid stalling.
BTW, when I say "HLS is pretty backwards" I mean designed unergonomically and without clear requirements in mind, not a step back from what existed before. I would guess this is because the original specification was something like "whatever Major League Baseball can easily stream from their existing setup" (see the various Pantos drafts that ultimately became RFC8216)
Oh you're quite right! I was definitely mis-remembering silverlight.
> Separate manifests and non aligned segments have a real impact on the ability of the client to switch qualities in responsabilità to bandwith change, and this to avoid stalling.
I don't know if that's actually true. I sell ads, so I'm collecting delivery data on billions of devices, but only over the crappy internet that has a lot of ads on it, and at least for short videos, and the long videos after the places those short videos are, HLS stalls less than Dash and silverlight: HLS publishers make more money.
I would be interested in learning more.
> I mean designed unergonomically and without clear requirements in mind
I can easily agree with that. I misinterpreted what you meant by "backwards" as referring to the progress of the experience.
Source: I write an HTTP streaming client library for a living.