HLS irregular chunking

Hi there … I’m using Wowza 4.0.3 and I’m having an issue as described below. I’d like to know if upgrading to 4.1 would fix this or not

Server is being used as CDN Origin

FMLE encodes and send RTMP to Wowza, with key frame every 10 secs.

Wowza is set up to generate HLS following default setting chunks of 10 secs

What I’m seeing right now is that chunks don’t follow those settings. It is actually chunking the stream at several sizes which go from 3 secs to 19 secs, in a very irregular way

CDN is caching the .m3u8 to 10 secs as well (which is correct) but when a chunk is only 3 secs, for instance, player tries to refresh the .m3u8, which will remain same for next 7 secs , which eventually causes a problem in the player as it runs out of buffer

I can work around this without caching .m3u8 for so long but it shouldn’t be the case. If I’m sending key frames every 10 secs, why isn’t Wowza creating chunks of 10 secs?

thanks

Hi,

Please add the following property to the LiveStreamPacketizer/Properties container in Application.xml.

This instructs the Wowza to log information for every HTTP chunk that’s created (not just the first 10 chunks).

<Property>
	<Name>maxChunkLogCount</Name>
	<Value>0</Value>
	<Type>Integer</Type>
</Property>

If you could post the logs showing chunks created for the stream with the issue that would be great.

After editing the Application.xml you will need to restart after saving for the changes to take effect.

Generally chunks vary in size when the keyframe frequency is not fixed as chunks are created on keyframes.

We recommend a keyframe be added every 1-4 seconds for live streaming.

Regards,

Jason

will do and post the results

I understand how chunks are created. My confussion is if I’m saying to chunk at every 10 secs, and I’m sending key frames every 10 secs from encoder, let’s say encoder sends a key frame by whatever reason at second 4 …, it shouldn’t be chunked at second 4 … it should still wait for second 10 and check if there is a key frame there … if not … wait for next one

My point is I’ve seend cases where chunks are more than 10 secs 'cause the key frame didn’t come … but I don’t see a reason for chunk to be at 3 secs for instance

Thanks