[Icecast] Webm files written without duration in header

Marvin Scholz epirat07 at gmail.com
Wed May 1 20:19:47 UTC 2019

On 1 May 2019, at 22:06, Sytze Visser wrote:

> Hi Fred.
> Appreciate your response.
> Maybe in my explanation I have some red and green apples, but I can
> agree that my understanding is as you explained it. 😊
> The point is that if I can successfully stream mp4 with H.264 and AAC
> encoding without any issues to icecast, I can then use ffmpeg to

just a quick thing to clarify before you waste too much time on this:

MP4 is not streamable due to the way the format works. The header/trailer
that a valid mp4 files needs to have, requires "knowledge" of the whole
file which makes it impossible to stream it.

What HLS or DASH does is not "streaming" in the "traditional" sense of
streaming but rather it is downloading small complete file chunks that
nowadays mostly use fragmented MP4.

You can't stream MP4 with Icecast.
If you for some reason have to stream H.264 you could use MPEG TS.
Note that this might have licensing implications as MPEG TS is not

> turn it into HLS which then solves my iOS support issue. The CPU
> cost of repackaging MP4 into HLS architecture should be minimal
> because at the core it’s all H.264. No transcoding! Low CPU objective
> achieved!
> Additional bonus is that I already use Apach2 with icecast and
> integrating the whole lot into my existing infrastructure is easy.
> My question remains
> If webm/ogv is supported but mp4 not, what are the technical differences
> in how icecast handles the one and not the other? What does icecast
> manage/do for supported formats as opposed to unsupported ones?
> Kind regards
> On Wed, 2019-05-01 at 19:56 +0200, Sytze Visser wrote:
>> I read somewhere that MP4 is not supported on icecast, which is a
>> pity. I have invested a lot in an icecast based audio solution and
>> want expand it with video.
> It all depends on what one means by 'MP4' (which is more a marketing
> term than a technical one). AAC+ (aka 'high efficiency' AAC) works very
> well on IceCast, albeit that only covers the audio side on the
> equation.
>> So my question is now:
>> MP4 (H.264) is a close relative of HLS (can also be H.264) which
>> brings me very close to a solution.
> You're mixing apples and oranges here (pun accidental). H.264 is a
> content encoding, like MPEG Layer III (so-called 'MP3') or OggVorbis.
> HLS OTOH is a streaming architecture, and as such is largely orthogonal
> to the content encoding used. It works by segmenting the media stream
> into discrete files and then distributing them via HTTP(S). The big
> advantage of this approach is that standard 'garden variety' web
> servers (think Apache) can be used to serve the streams, which makes it
> play particularly well with CDNs, at the cost of significantly greater
> complexity in the encoder and player components. No specialized
> 'streaming server' (such as Icecast) is required in the HLS ecosystem
> at all.
> Cheers!
> |---------------------------------------------------------------------|
> | Frederick F. Gleason, Jr. |             Chief Developer             |
> |                           |             Paravel Systems             |
> |---------------------------------------------------------------------|
> |  An expert is a person who avoids the small errors while he sweeps  |
> |  on to the grand fallacy.                                           |
> |                                                                     |
> |                                              -- Benjamin Stolberg   |
> |---------------------------------------------------------------------|
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

More information about the Icecast mailing list