HLS requires the MPEG2-TS container format, which is not royalty free and therefore has no chance of becoming a web standard or of being implemented by Mozilla on free platforms.
I don't see the double standard. All but one browser on GP's platform support the royalty free option. Only Safari on his platform supports the encumbered option, and he doesn't want to be forced to use it. On my own preferred platform, no browsers support HLS.
Since the votes on this thread won't let me reply:
@pjmlp: I choose to use a platform where developer experience is the primary goal because developing software is both my vocation and avocation and why I am reading "Hacker News." If I wanted a walled garden media consumption toy, I would get a LeapPad. Look, we can snark all day, but that doesn't change the conclusion that tommoor was right about web standards.
@millstone: There are no royalty-required formats that are web standards for a reason: to make the web free and open to all. That is why it is not a red herring. Bringing Google into it, on the other hand, is — whether Google pays the fees has no bearing on whether the format should be a web standard. Apple chose not to implement hardware decoding for the unencumbered format. All other major consumer hardware manufacturers have.
Not that I like HLS even a tiny bit, but even if MPEG2-TS was patent encumbered (and I'm not sure it is) HLS now supports fragmented MP4 just like DASH (this was done so that content providers don't need to store two different muxings of the video for DASH and HLS).
Apple, as usual, wrote their own private format. A pretty sucky one at that. But don't get fooled, DASH is not much better, and for the few things it offers over HLS it comes with a massive implementation difficulty. There is basically no DASH compliant player around, not even the one developed by the DASH Industry Forum implements all the standard. It would be way easier for every browser vendor to support HLS than DASH.
"Royalty free" seems like a red herring. I'm not familiar with MPEG2-TS in particular, but Chrome already happily plays H.264 on macOS, plus there is an explicit exception in H.264 license for non-paid (including ad-supported) content. I don't see how implementing HLS would increase Google's licensing cost in any way.
I appreciate the free software position. It seems MPEG-DASH is indeed better suited for it, though maybe only slightly [1]. (Regardless, turns out Apple did not release anything as copyleft this year, so maybe it's better that free software purists could not have watched the video?)
The case for "encumbered" options is simple: it's what's decoded in hardware, for users who prefer their device to last the entire video.
If Apple used fMP4 for this video, that gives them no excuse not to support other browsers. They can just ship a JavaScript HLS client built on the MSE web standard on the web page.
I don't see the double standard. All but one browser on GP's platform support the royalty free option. Only Safari on his platform supports the encumbered option, and he doesn't want to be forced to use it. On my own preferred platform, no browsers support HLS.
Since the votes on this thread won't let me reply:
@pjmlp: I choose to use a platform where developer experience is the primary goal because developing software is both my vocation and avocation and why I am reading "Hacker News." If I wanted a walled garden media consumption toy, I would get a LeapPad. Look, we can snark all day, but that doesn't change the conclusion that tommoor was right about web standards.
@millstone: There are no royalty-required formats that are web standards for a reason: to make the web free and open to all. That is why it is not a red herring. Bringing Google into it, on the other hand, is — whether Google pays the fees has no bearing on whether the format should be a web standard. Apple chose not to implement hardware decoding for the unencumbered format. All other major consumer hardware manufacturers have.