Re: why HLS/DASH are problematic in an Icecast context

On 20 Feb 2015, at 17:59, Ralph Giles wrote:

> 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. :)

That sounds like a great Idea, I already thought about similar, seeing 
so many same streams where the only difference are bitrates on the 
stream directory.

>
> -r
> _______________________________________________
> Icecast-dev mailing list
> [email protected]
> http://lists.xiph.org/mailman/listinfo/icecast-dev