5 ms·

Not forcing us to use Safari

millstone 9y ago
I get that you don't want to use Safari, but actually "forcing us to use Safari" is exactly what Google did. Google chose not to implement HTTP Live Streaming, and therefore it's not available in Chrome. Microsoft made the other choice, which is why it works in Edge. The double standard here is really quite breathtaking. Apple doesn't implement a feature: Apple's fault. Google doesn't implement a feature: Apple's fault too.
- lern_too_spel 9y ago
  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.
  - pjmlp 9y ago
    > On my own preferred platform, no browsers support HLS. Then chose platforms where the overall desktop experience is a primary goal of developers.
  - millstone 9y ago
    "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. [1] http://www.streamingmedia.com/Articles/News/Online-Video-News/MPEG-LA-Announces-MPEG-DASH-Patent-Portfolio-License-114873.aspx http://www.streamingmedia.com/Articles/News/Online-Video-New...
  - lultimouomo 9y ago
    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.
    - astrange 9y ago
      MPEG-TS, MPEG1 video and MP3 are all patent free. MPEG2 will be patent free in Feb 2018.
  - duvrai 9y ago
    HLS can now use the same royalty free fMP4 segments used for MPEG-DASH. Ironically fMP4 is royalty free thanks to its original developer, Apple.
    - lern_too_spel 9y ago
      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 get that you don't want to use Safari, but actually "forcing us to use Safari" is exactly what Google did. Google chose not to implement HTTP Live Streaming, and therefore it's not available in Chrome. Microsoft made the other choice, which is why it works in Edge. The double standard here is really quite breathtaking. Apple doesn't implement a feature: Apple's fault. Google doesn't implement a feature: Apple's fault too.

lern_too_spel 9y ago
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.
- pjmlp 9y ago
  > On my own preferred platform, no browsers support HLS. Then chose platforms where the overall desktop experience is a primary goal of developers.
- millstone 9y ago
  "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. [1] http://www.streamingmedia.com/Articles/News/Online-Video-News/MPEG-LA-Announces-MPEG-DASH-Patent-Portfolio-License-114873.aspx http://www.streamingmedia.com/Articles/News/Online-Video-New...
- lultimouomo 9y ago
  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.
  - astrange 9y ago
    MPEG-TS, MPEG1 video and MP3 are all patent free. MPEG2 will be patent free in Feb 2018.
- duvrai 9y ago
  HLS can now use the same royalty free fMP4 segments used for MPEG-DASH. Ironically fMP4 is royalty free thanks to its original developer, Apple.
  - lern_too_spel 9y ago
    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.