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