|
|
|
|
|
by antimagic
3935 days 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. |
|