Icecast dev - Feb 2015 - why HLS/DASH are problematic in an Icecast context

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

Hi Thomas,
> Let's start with HLS:
> - It's not a standard. It's current status is that it's an
*expired*
> draft[1].
Does that suggest a lack of interest in an open standard? The expired
doc says:

The ID3 PRIV owner identifier MUST be
   "com.apple.streaming.transportStreamTimestamp"

Proposed mimetype:

   Type name: "application"

   Subtype name: "vnd.apple.mpegurl"

Maybe they never intended anyone other than Apple to use it :-)
> - 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."
I don't understand why this has to be so limited, because the basic
idea, as I understand it, is to extend the .m3u playlist format so that
stream listeners can automatically choose alternative sources for the
same content. That could be implemented in a codec-agnostic way.

Cheers!

Daniel

On Fri, Feb 20, 2015 at 10:25 AM, Daniel James <
daniel.james at sourcefabric.org> wrote:
> Hi Thomas,
> > Let's start with HLS:
> > - It's not a standard. It's current status is that it's an
*expired*
> > draft[1].
>
> Does that suggest a lack of interest in an open standard?

I'm actually not sure how it is expired... The most recent HLS draft was
published in October and is valid through April:

https://tools.ietf.org/html/draft-pantos-http-live-streaming-14

As someone who has been implementing both a server and client around HLS,
it's actually been a little more active of a document than I would wish.

Thomas has some valid questions around implementability for Icecast, but I
wanted to take a second to provide a little context for why I as a
broadcaster like HLS.

I work for Southern California Public Radio, the largest NPR affiliate in
the Los Angeles market. We're a small-to-medium online streamer, peaking at
roughly 3k concurrent on an average day, but we think that's going to grow
rapidly over the next few years and that Internet listening on mobile
devices is the future.

For us, the short-lived connections in an HLS session seem to map more
cleanly onto how people use their devices. We want them to start listening
at home (WIFI) and keep listening as they hop in the car (maybe bouncing
from 3G to LTE) and then arrive at the office (another WIFI network).
That's 3-4 IP addresses over the course of a listening session. Because we
don't have to keep one connection alive, HLS handles that on today's
network routing realities (at least in theory... The implementation doesn't
create a 100% perfect experience today).

ER
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast-dev/attachments/20150220/fe8f5a53/attachment.htm

On 2015-02-20 7:25 AM, Daniel James wrote:
> I don't understand why this has to be so limited, because the basic
> idea, as I understand it, is to extend the .m3u playlist format so that
> stream listeners can automatically choose alternative sources for the
> same content. That could be implemented in a codec-agnostic way.
Stitching together compressed media streams for gapless playback isn't
trivial, and in particular while .ogg and .opus support sample-accurate
cuts and cross-lapping for gapless transitions between arbitrary
segments, mp3 and aac do not. Moreover, part of the point of HLS was to
support bitrate switching for video, so there's an additional
synchronization constraint.

As I understand it, the mpeg2-ts and related restrictions on audio
segmentation come from these constraints this. Unlike mp4, and like ogg,
mpeg2-ts doesn't have a seek table, so it's a better format for
splicing. It's probably also all Apple wanted to implement.

One thing I think icecast could do in this space is to provide a way to
declare groups of streams as having the same content, but different
bitrates or formats. That would let player authors select the best
stream for their application and current network conditions. Including
implementing that by generating their own HLS manifest. :)

 -r