Wowza Community

playlist.m3u8 not immediately available

We have Wowza 3.1 together with the transcoder addon.

The use case is a sender broadcasting audio over RTMP and the receiver listens using HTTP Live Streaming by accessing the appropriate playlist.m3u8 file. The issue is that the playlist.m3u8 does not seem to immediately contain the data chunks needed to listen to the stream (a valid playlist.m3u8 file is present ~5 seconds after the broadcast starts). Starting listening “too early” will never lead to any audio output.

Is there a workaround for this problem other than waiting for an arbitrary amount of time on the listeners side before trying to access the playlist.m3u8 file? Perhaps a configuration that generates some sort of intermediate playlist.m3u8 file that will eventually (after the initial ~5 seconds) be filled with the data chunks constituting the broadcasted audio stream?

Best,

Claudijo

Claudijo,

Welcome.

There isn’t anything like that built-in to Wowza. Flash RTMP clients will not have this issue, if that is an option.

Richard

when pausing and resuming a RTMP broadcast, in which case the playlist.m3u8 file will only contain audio broadcasted prior to the pause

Wowza doesn’t pause the incoming live stream, it just ends, the packetizer is destroyed. Then it starts new.

Looking at the API, there is ILiveStreamPacketizerActionNotify.onLiveStreamPacketizerCreate() and ILiveStreamPacketizer.isActive(), but it doesn’t seem like those help tell when there is enough chunks to playback.

Also take a look at this article.

https://www.wowza.com/docs/how-to-configure-apple-hls-packetization-cupertinostreaming

Richard

I don’t think those will help. If they did, you would still have to do something with that info. It would involved custom module, using WMSProperties and onHTTPSessionCreate. Then you would do httpSession.redirectSession() or httpSession.rejectSession(), but I don’t think the hooks are there to do that.

Is the 5 seconds that a stream cannot be played while packetizing is begun really that much of an issue?

Richard

Claudijo,

Along those lines, you could try counting chunks using ILiveStreamPacketizerActionNotify.onLiveStreamPacketizerCreate(), and store a “ready_or_not” flag for that stream in the app instance using WMSProperties. Then use a HTTPProvider to poll that flag. Once there are 3 chunks the stream should be ready to play.

Rihcard

Thanks for the reply. I must however double check… Is there really no way to know if a playlist.m3u8 file is ready for consumption, after a RTMP broadcast stream has started?

This is also an issue when pausing and resuming a RTMP broadcast, in which case the playlist.m3u8 file will only contain audio broadcasted prior to the pause, if consumed too early.

Best,

Claudijo

Thanks for the tip. Could perhaps ILiveStreamPacketizer.startStream(IMediaStream stream) - “Called when the stream starts” be used to tell when the playlist is ready for consumption?

Thanks Richard,

Is the 5 seconds that a stream cannot be played while packetizing is begun really that much of an issue?

Richard

We develop a real time one-to-many voice broadcast feature, where one sender is using a desktop browser with Flash as RTMP endpoint, and one or many listeners use Flash and RTMP or HTTP Live Streaming (the latter is typically clients running iOS Safari or our native iOS app). When the sender starts the voice broadcast a control message is sent to the listeners, to start listen, and if the listeners on iOS start to listen to early they will not hear anything.

Relying an an arbitrary timeout before the listeners in iOS start to consume the chunks in the playlist would be quite unreliable, and some sort of polling or event to let them know the playlist is ready for consumption is really what we need.

Does this explanation give you any further ideas on how to attack the problem?

// Claudijo