OK, this is one of things where you have to be very precise with the terminology.  HLS does enforce the use of MPEG-2 <i>Transport</i> 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&#x27;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.<p>I don&#x27;t know that you can really say that DASH is more technologically neutral.  I mean what are you saying, that HLS is <i>not</i> technology neutral because it forces you to use an MPEG specification, but if you opt to use an MPEG specification up-front, that&#x27;s neutral?<p>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&#x27;re only implementing one specific profile, in which case content providers complain that you&#x27;re not supporting <i>their</i> chosen profile, or you have to write an absolutely massive client that can accept anything thrown at it.<p>Apple&#x27;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&#x27;t have to bloat all of their code handling all of the different options.  Because don&#x27;t forget, the servers don&#x27;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.