Re: 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