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

[Greg Ogonowski]

The idea of HLS is to use a simple web server or cloud storage to stream
live or deliver files to a player.
ADTS AAC/HE-AAC in either TS or ES has no problem with stitching together,
provided it is done at the frame boundaries. It should be noted, that using
TS for low bitrate audio streaming is not a good idea because of the
excessive TS overhead. 
More information here:
https://www.indexcom.com/products/encoder/

/greg.
StreamS/Modulation Index
Formerly of Orban


-----Original Message-----
From: icecast-dev-bounces at xiph.org [mailto:icecast-dev-bounces at xiph.org] On
Behalf Of Ralph Giles
Sent: Friday, 20 February, 2015 08:59
To: Daniel James; icecast-dev at xiph.org
Subject: Re: [Icecast-dev] why HLS/DASH are problematic in an Icecast
context

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
_______________________________________________
Icecast-dev mailing list
Icecast-dev at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast-dev