We recently enabled streaming of audio-only Apple HLS using transport stream (https://www.wowza.com/docs/how-to-configure-wowza-server-to-stream-audio-only-apple-hls-using-transport-stream) to allow JW Player 6 to play iOS audio-only streams from wowza. While that did the trick, it resulted in playback issues on iOS devices when using a poster frame. Playback is at a faster speed than normal with long pauses in between. Also, the poster frame takes a good 10-15 seconds to show up. On setting cupertinoPacketizeAllStreamsAsTS to false, playback is normal with the poster frame showing up immediately.
Is this a known issue where a combination of poster frames + packetizing HLS as TS causes problems? If so, is there a fix in the works? We’re testing this with Wowza 3.6.2 patch 10.
Do you need to use that setting? Poster frames are designed to work with audio only, which normally contain .aac or .mp3 chunks instead of .ts chunks. Since it works well in your test without that setting, what is the case for turning it on?
In my test the poster frame did not work with cupertinoPacketizeAllStreamsAsTS set to “true”. I tested the poster frames on a live stream following this guide
I will let Engineering know. Thanks for the report,
We reviewed this, Engineering looked at it and determined that it is not supported at present. It’s a player issue really, as I indicated initially. The player does not expect post frames in .ts chunks.
I don’t think this can be done per playback client. Wowza is packetizing one way or the other. I looked at the HTTPStreamerSessionCupertino api to be sure, and there is no method to do that.
We have customers who use JWPlayer 6 which supports HLS. For audio-only delivery however, it requires that the chunks need to be TS, which is why we enabled the property.
In that case, is it possible to set the cupertinoPacketizeAllStreamsAsTS property on a per feed basis? That way, we only packetize specific feeds in TS chunks for customers that do use JWPlayer 6.
Not on the output side, but the ingest. At the point the Encoder pushes a stream to the Live Repeater Origin. Right now, the property is set on a per-application basis, but that’s not going to work for us.