Icecast - May 2019 - Webm files written without duration in header

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20190501/b1b66c92/attachment.html>

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
Hi,
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
royalty-free.
> 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

On Wed, 2019-05-01 at 22:06 +0200, Sytze Visser wrote:
> 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
> 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!
So all FFMPEG is doing is segmenting the stream and generating the m3u8
index? Yes, I'd expect that to be quite efficient.

> 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?
It's been a few years since I looked at the source, but IIRC adding
support for a new codec is pretty simple -- mostly a matter of getting
it to recognize and emit the correct mimetype(s).

Of course, you'll also need an ICES client that is capable of
supporting the desired codec. That may be more challenging than hacking
Icecast itself.

Cheers!


|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |             Chief Developer             |
|                           |             Paravel Systems             |
|---------------------------------------------------------------------|
|  There is only one thing worse than having your competitors trying  |
|  to inter-operate with your systems - and that is to have your      |
|  competitors *not* trying to inter-operate with your systems.       |
|                                                                     |
|                                          -- Alan(UK), GrokLaw.net   |
|---------------------------------------------------------------------|

On 1 May 2019, at 22:30, Fred Gleason wrote:
> On Wed, 2019-05-01 at 22:06 +0200, Sytze Visser wrote:
>> 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
>> 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!
>
> So all FFMPEG is doing is segmenting the stream and generating the m3u8
> index? Yes, I'd expect that to be quite efficient.
Depending how you segment the stream it can be very efficient as only
remuxing is required in some cases.
>
>
>> 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?
>
> It's been a few years since I looked at the source, but IIRC adding
> support for a new codec is pretty simple -- mostly a matter of getting
> it to recognize and emit the correct mimetype(s).
It is not as trivial as that, basically Icecast needs to be able to
properly packetize the format and ideally read metadata from it.

Especially for video it can be even more complex, as ideally Icecast
would ensure to send clients video data starting with a keyframe
if one is in the buffer.

And as I already wrote in my last mail, MP4 is not streamable.
>
> Of course, you'll also need an ICES client that is capable of
> supporting the desired codec. That may be more challenging than hacking
> Icecast itself.
>
FFMpeg is already capable to stream nearly any format to Icecast, of
course if it works or not depends a lot on the format as for all
unsupported formats Icecast does no handling whatsoever.
> Cheers!
>
>
> |---------------------------------------------------------------------|
> | Frederick F. Gleason, Jr. |             Chief Developer             |
> |                           |             Paravel Systems             |
> |---------------------------------------------------------------------|
> |  There is only one thing worse than having your competitors trying  |
> |  to inter-operate with your systems - and that is to have your      |
> |  competitors *not* trying to inter-operate with your systems.       |
> |                                                                     |
> |                                          -- Alan(UK), GrokLaw.net   |
> |---------------------------------------------------------------------|
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

Hi Marvin

I followed this advice for updating moov flags in mp4 and it "streams"
directly from the file location on the server with html5 video:
https://rigor.com/blog/optimizing-mp4-video-for-fast-streaming.

Progressive downloading, seeking and video time all works 100% on a 195MB
file.

Regards

On Wed, May 1, 2019 at 10:19 PM Marvin Scholz <epirat07 at gmail.com>
wrote:
>
>
> 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
>
> Hi,
> 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
> royalty-free.
>
> > 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
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20190502/e406576a/attachment.html>