[Icecast-dev] why HLS/DASH are problematic in an Icecast context

["Thomas B. Rücker"]

Hi,

as there seems to be some interest in this topic, I'm opening a separate
thread.
Also please use proper in line comments and do NOT top post, as top
posting breaks readability and discussion flow.

Let's get some things out of the way:
I'm going to acknowledge that HLS and DASH are things that are out
there. Especially HLS is being pushed by the likes of Apple, in parts
quite aggressively.

Icecast is a open source multi media streaming server that emphasizes
open codecs and formats.


I've been repeatedly thinking if Icecast should add support for one of
these. Each time I arrive at a rather clear:
No, it doesn't make sense.

Let's start with HLS:
- It's not a standard. It's current status is that it's an *expired*
draft[1]. It's been mostly pushed by Apple.
- It requires formats that are not well supported by Icecast:

   "Each media segment MUST be formatted as an MPEG-2 Transport Stream
   [ISO_13818], an MPEG audio elementary stream [ISO_11172], or a WebVTT
   [WebVTT] file."

So the primary supported formats of Icecast can't be streamed this way.
No WebM and no Opus, Vorbis, sorry.

The second named format is most commonly encountered as "MP3". The
problem here is, that it would require us to actually interpret the
stream, something that we've been avoiding for problematic content types
(like MP3 and AAC) due to IPR concerns. This is because you can't just
slice this up at random points in the bit stream, you should have frames
and maybe even some headers.

Given that MP3 is nowadays a quite inferior codec and e.g. Opus has
actually seen quite good adoption, I just don't see value in adding
support for HLS, which would *only* benefit problematic codecs.


Let's proceed to DASH - Dynamic Adaptive Streaming over HTTP:
- It's done by MPEG, that's a big warning light in terms of IPR and
"openness".
- It doesn't mandate a specific format but endorses ISO base (aka MP4
container) and MPEG2-TS
- It seems to have been originally born in Adobe out of the fact that
Flash couldn't handle a continuous stream and would leak it into memory.
- I hear "industry adoption" is rather slow or even decreasing.

So I'm again suspicious of this, it has MPEG written all over it and I
wouldn't like to see my life ruined by some big corporation deciding
that Icecast infringes on "their IPR" and sues the maintainer (me). If
someone wants to go and prove that it can be made to work with Ogg and
EBML (WebM), be my guest. Could even be a GSoC thing, as we will
hopefully participate this year. Another concern is players, we've seen
how horrible support for Ogg-chaining was for years, and even such
shining open source projects as Firefox had it broken for 4 years(sic!).
Could support for DASH output be merged into Icecast? I honestly don't
know and would like to see a legally solid opinion on my concerns first.
Sorry, arm chair lawyers need not apply, thanks.


A common benefit that I must give both of those is, that they allow for
moderately sensible quality switching to adapt to bandwidth problems. I
see this as much more relevant for video content on demand, than for
live streaming. Still, a player could, if it supports DASH, also switch
between continuous HTTP streams if they would provide the same kind of
synchronization data (timestamps). How likely is this going to see
generic adoption? Not very likely, but should be rather easy if someone
wants to do it.


Time to put on my asbestos underwear and jump suit. Flame on!


Cheers

Thomas

1) http://tools.ietf.org/html/draft-pantos-http-live-streaming-13