[gnulinux996]

I am curious, why would anyone pick HLS over Dash in these days?

Granted, my knowledge on the matter is rather limited, but I had some long running streams (weeks) and with HLS the playlist became quite large while with dash, the mpd was as small as it gets.

[KingMob]

It's still mandatory for all but the newest iOS devices, which don't support MediaSourceExtensions.

[Heff]

This is true, and the whole iOS/iPadOS/tvOS ecosystem supports HLS natively making it much easier to work with on that platform. In addition, Chrome recently added support for HLS[1] (and not DASH), so the native browser support for HLS is getting pretty wide.

HLS also has newer features that address the growing manifest issues you were seeing. [2]

All that said, I think a lot of people would feel more comfortable if the industry's adaptive streaming standard wasn't completely controlled by Apple.

[1] https://caniuse.com/http-live-streaming

[2] https://www.mux.com/blog/low-latency-hls-part-2

[Retr0id]

How do you actually use HLS in the form of a native browser feature? Can you just put the m3u8 in the video src?

[pjc50]

Yes, doing that works perfectly. If you use videojs it will automatically use native support if present.

[cpillsbury]

Core VJS contributor here and builder of players and playback engines for too long (aka before HLS and MPEG-DASH were a thing). As others mentioned, the support matrix for HLS is very typically the proximate, pragmatic reason why folks will reach for HLS over DASH in a "pick one" situation. You're right that HLS is particularly bad for 24/7, long lived DVR/"EVENT" (to use HLS jargon) streams (fine for live, and there are some "cheats" you can do for EVENT to help there) compared to MPEG-DASH's <SegmentTemplate>-based "dynamic" MPEG usage.

Outside of that, though, the standards themselves have different pain points and tradeoffs. Some things are "cleaner"/"less presumptuous" in DASH, but DASH also has a lot of design details that were both "design by committee" (aka different competing interests resulting in a spec that has arguably too many ways to do the same thing) and overrepresented by server-side folks (so many playback complexities/concerns/considerations weren't thought through). It is also sometimes not constrained enough, at least by default (things like not guaranteeing time alignment across media representations). For what it's worth, I think there are lots of pain points from the HLS design decisions as well, but focusing on DASH here just given the framing of your question.

On the flip side, if you stay within certain bounds, the difference between HLS and DASH simply become text files: one XML manifest (MPD) for DASH and a few playlists (M3U8s) for HLS. There's a lot of effort being made to this end, including: https://cdn.cta.tech/cta/media/media/resources/standards/cta... and the CMAF-HAM-inspired model (https://github.com/streaming-video-technology-alliance/commo... from CML and https://github.com/videojs/v10/blob/main/packages/spf/src/co... in our own playback engine library), just to name a few.