5 ms·

Actually HLS is an IETF draft [1], but I'm not sure why Apple never followed through on making it a full standard because it's got a ton of clear advantages to

by atonse 11y ago

Actually HLS is an IETF draft [1], but I'm not sure why Apple never followed through on making it a full standard because it's got a ton of clear advantages to traditional streaming technologies. I think it's more an issue of other browsers not supporting it, rather than Apple stopping them. 1: https://tools.ietf.org/html/draft-pantos-http-live-streaming-16 https://tools.ietf.org/html/draft-pantos-http-live-streaming...

vetinari 11y ago
HLS requires you to use MPEG-2 streams[1], so it will not work with non-MPEG streams, like WebM. 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].
- atonse 11y ago
  Oh yikes I didn't know that :) That's pretty bad. 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.
- mikeash 11y ago
  Is there a reason you couldn't put VP-8 video and Vorbis audio into an MPEG Transport Stream?
- antimagic 11y ago
  OK, this is one of things where you have to be very precise with the terminology. HLS does enforce the use of MPEG-2 Transport streams, but it does not force the use of the video encoding that is packaged in the stream. It is very typical (in fact it's the norm) to see HLS using H264 for the actual encoding work, and MPEG2 TS is actually a pretty decent specification for throwing around video streams. 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.

by atonse 11y ago

vetinari 11y ago

HLS requires you to use MPEG-2 streams[1], so it will not work with non-MPEG streams, like WebM. 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].

atonse 11y ago
Oh yikes I didn't know that :) That's pretty bad. 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.
mikeash 11y ago
Is there a reason you couldn't put VP-8 video and Vorbis audio into an MPEG Transport Stream?
antimagic 11y ago
OK, this is one of things where you have to be very precise with the terminology. HLS does enforce the use of MPEG-2 Transport streams, but it does not force the use of the video encoding that is packaged in the stream. It is very typical (in fact it's the norm) to see HLS using H264 for the actual encoding work, and MPEG2 TS is actually a pretty decent specification for throwing around video streams. 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.