Interesting. They are limiting it to their own devices and software, except they allow Microsoft Edge. Is there a technical reason for this? Couldn't Chrome/Firefox work? Strange that they would give Edge an exception.
Interesting. They are limiting it to their own devices and software, except they allow Microsoft Edge. Is there a technical reason for this? Couldn't Chrome/Firefox work? Strange that they would give Edge an exception.
- Chrome (and other browsers) support MPEG-DASH via javascript through the Media Source Extensions (MSE) (which Safari actually supports[1])
- Firefox does not "bundle" H.264 (because of licensing) but has recently supported it where the OS provides it[2].
- HLS and MPEG-DASH are fairly similar in theory, but in practice HLS requires complete (with header/metadata) chunks whereas MPEG-DASH can "arbitrarily" chunk a video file and just feed into a MSE video stream. Both work with manifest files detailing different resolutions/qualities and chunk sizes + offsets.
[1] https://en.wikipedia.org/wiki/Media_Source_Extensions#Browse...
[2] https://developer.mozilla.org/en-US/Apps/Build/Audio_and_vid...
https://gigaom.com/2014/10/14/h-264-support-arrives-in-firef...
https://github.com/cisco/openh264
and the code is better than I expected from a commercial project, it even uses may_alias properly. I wonder why the decoder doesn't support CPU multithreading, though? Slice threads are pretty simple to add.
"while OpenH264 is not truly open, at least it is the most open widely used video codec"
Normal videos like youtube uses the operating system decoder.
1: https://tools.ietf.org/html/draft-pantos-http-live-streaming...
DASH is more technologically neutral. For Apple however, it is NIH.
[1] - from the spec: Each media file MUST be formatted as an MPEG-2 Transport Stream or an MPEG-2 audio elementary stream [ISO_13818].
I don't know that you can really say that DASH is more technologically neutral. I mean what are you saying, that HLS is not technology neutral because it forces you to use an MPEG specification, but if you opt to use an MPEG specification up-front, that's neutral?
Anyway, as someone that writes the client code for these things, I much prefer the HLS approach. If you go the DASH approach, you get into one of several potential messes. Either you have to say that you're only implementing one specific profile, in which case content providers complain that you're not supporting their chosen profile, or you have to write an absolutely massive client that can accept anything thrown at it.
Apple's affection for HLS stems from this same reasoning in my opinion. They too are more concerned about the client side - they want to keep the format simple for clients to handle, so that they don't have to bloat all of their code handling all of the different options. Because don't forget, the servers don't have to deal with this complexity - they choose which bits they want to use and go with it. Clients have to be able to handle everything in the spec correctly.
But this is exactly the kind of thing where you can update the draft to support better codecs, but Apple seems to have just abandoned it.