Ralph Giles
2015-Feb-20 16:59 UTC
[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
Marvin Scholz
2015-Feb-20 17:03 UTC
[Icecast-dev] 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 > Icecast-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast-dev
Daniel James
2015-Feb-20 17:42 UTC
[Icecast-dev] why HLS/DASH are problematic in an Icecast context
Hi Ralph,>> > 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 > trivialI'm sure. I can see why limiting the spec makes sense for Apple, and anyone else whose goal is to support Apple devices only. I just thought that a standard could specify the playlist format without forcing a particular codec, since better codecs might come along...> .ogg and .opus support sample-accurate > cuts and cross-lapping for gapless transitions between arbitrary > segmentsThat sounds good! Maybe someone should tell Apple :-) Daniel
Greg Ogonowski
2015-Feb-20 17:50 UTC
[Icecast-dev] why HLS/DASH are problematic in an Icecast context
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
Daniel James
2015-Feb-23 11:56 UTC
[Icecast-dev] why HLS/DASH are problematic in an Icecast context
Hi Marvin, hi Ralph,>> 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.Some of the streaming stations I know of use a .pls file for a crude approximation of this, while adding some redundancy. The first URL is the main high bitrate stream, the second URL is their backup streaming server with a lower bitrate, and the third URL is a static emergency file in case the stream source goes down for both servers. They rely on the player skipping to the next playlist item when the stream goes down, but of course there's no sync, and no returning to the higher bitrate stream without the user restarting the playlist. Cheers! Daniel