Over a million developers have joined DZone.

Apple Can't Obey Its Own Specifications

· Mobile Zone

Visually compose APIs with easy-to-use tooling. Learn how IBM API Connect provides near-universal access to data and services both on-premises and in the cloud, brought to you in partnership with IBM.

I’ve been playing around with a basic implementation of HLS the last few days, and despite it being a proprietary streaming transport there is a public specification available for it which seems reasonably complete. That being said, it is still proprietary, hasn’t made it through the standardization process and the public spec is suspected of being at least partially incomplete. THAT being said, I still managed to get both iTunes and an iPad working with it just based on my reading of the specification, so it has enough to get by.

However, as I worked through the small number of bugs I had in my implementation, firstly only iTunes would play back content but not the iPad. Later when I had fixed the bugs, the situation was reversed and only the iPad could play back but not iTunes. One would think that a desktop app would be more lenient with faulty implementations on the server side than a portable device which may not always be kept up to date, but apparently not!

It turns out that iTunes (at least 11.0.2 build 26) doesn’t actually implement Apple’s own specification properly, in that it can’t handle media segment URIs relative to the URI of the m3u8 playlist. This has been in the specification since at least draft 3 of the public specification, released April 2, 2010. Here’s what the playlist should (or could) look like:


With no further specification, the HLS client should request the media file at the same path level (and from the same server) as the playlist file. Unfortunately iTunes seems to require the full URI to the media segments:



It’s not the end of the world, but it is unnecessary, and a requirement that died almost three years ago when the second draft specification expired. The other side-effect of this is that your playlists will now contain more data. If you are attempting to stream very long tracks and with reasonably short media segments, this means you have a much longer startup time due to the size of the playlist being bigger and thus being a larger download for the player before it can start requesting media segments.

The main mechanism by which we could offset this is also seemingly not present in iTunes – gzip content encoding. ITunes makes no attempt to negotiate any compression in the response, which was part of the specification since draft 4, released June 5, 2010. It mystifies me that Apple can stay so far behind in its own streaming transport with its flagship music playback software and yet clearly keep its devices implementing the same streaming mechanism up to date (at least enough to be useful).

The Mobile Zone is brought to you in partnership with Strongloop and IBM.  Visually compose APIs with easy-to-use tooling. Learn how IBM API Connect provides near-universal access to data and services both on-premises and in the cloud.


Published at DZone with permission of Oliver Hookins , DZone MVB .

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}