Wowza Community

Overhead HLS

Hi.

If you have an mp4 at lets say 40k/bits. What kind of overhead can you expect when playing it back as an HLS stream? From what it looks like (server v2.2.x) it adds almost 40-45 K/bits. Is that to be expected? That would mean that you would need to have the file at 20 K/bits to pass the app store inspection (lowest stream must be below 64 K/bit).

Do wowza support an .aac as source and play it back as HLS? Just trying to figure out how to get such a low bitrate stream that will actually pass the apple inspection.

BR

//D

There should be little or no added bandwidth usage to the network. The process of creating chunks for Cupertino streams adds some overhead to the server: memory use

Richard

If you do audio only. Which is what is suggested here then the overhead is very, very small since we deliver using AAC packets rather than TS:

https://www.wowza.com/docs/how-to-create-apple-app-store-compliant-streams

Charlie

We do not support raw AAC files. Only AAC in an MP4 container.

Our TS implementation does not group video frames into a single logical PES packet which would improve the overhead. It is something we may add in the future. This is what leads to the overly high overhead.

Charlie

Again, it is something we will most likely improve in a future version.

Charlie

Thank you for your reply.

The cost of the ts container is usually around 20 K/bits at the 64K/bit in the scenarios when I´ve done this with true HLS streams (presegmented files). From the wowza I saw almost the double, so that´s why I asked. Is there some tuning that can be done to get the overhead down?

How about delivering an audio only .aac file as the lowest stream? Is it possible?

//D

If you do audio only. Which is what is suggested here then the overhead is very, very small since we deliver using AAC packets rather than TS:

https://www.wowza.com/docs/how-to-create-apple-app-store-compliant-streams

Charlie

Thank you Charlie.

I tested it with an audio only aac file within an mp4 container and that seems to work with very little overhead. I couldn´t get it to use a .aac file as a source though.

Getting back to the large overhead I saw, yes I did test it with a “crappy low res, low fps” A/V source. Is the 35-40K/bits to be expected from the wowza? Just thinking about the sub 128 K/bit stream the customer needs as well and if we need to keep the actual A/V below 90 K/bits in that case? (Easy to tes, but just to make sure we haven´t done anything stupid with our setup).

BR

/D

We do not support raw AAC files. Only AAC in an MP4 container.

Our TS implementation does not group video frames into a single logical PES packet which would improve the overhead. It is something we may add in the future. This is what leads to the overly high overhead.

Charlie

Ah, ok so thats why I saw the extensive overhed. For streams over 500K/bits I wouldn´t care that much, it´s just for the low bandwidth stuff it might become troublesome.

Thank you for your explanation.

BR

//D