We are noticing that serving iPhone streaming media (not live) is taking a long time to begin playing, either on the iPhone or on a mediaplayer such as vlc on a computer. For example, http://176.34.178.1:1935/vod/mp4:1434-26223.mov/playlist.m3u8 currently takes around 20 seconds to start playing. This has been encoded using the ipod320 preset (as described here). When I encoded it using the ipod640 preset, the file took even longer (around 35 seconds or more) to start playing.
My colleagues report to me that this did not used to be the case, so something has changed. Are we somehow using a non-optimal format for uploading the file? Is there some way for it to be streamed that starts much faster? I note that the sample files provided by wowza begin in 6-9 seconds. This still seems a little too slow for our liking. Those links are structured differently from this, though, without the playlist.m3u8 - I haven’t been able to find out how to make our media stream match this approach, nor work out what exactly is different.
My understanding is that the EC2 build for Wowza is already tuned and optimized so I can’t work out what else we could do, unless I’m missing something! Any advice very gratefully received.
You can improve this with short key frame frequency and cupertinoChunkDurationTarget. Take a look at this guide:
https://www.wowza.com/docs/how-to-configure-apple-hls-packetization-cupertinostreaming
Richard
Did changing the chunk count have any effect on the delay? I found to have little difference in the start time over 3G network. Wifi works fine.
We are noticing that serving iPhone streaming media (not live) is taking a long time to begin playing, either on the iPhone or on a mediaplayer such as vlc on a computer. For example, http://176.34.178.1:1935/vod/mp4:1434-26223.mov/playlist.m3u8 currently takes around 20 seconds to start playing. This has been encoded using the ipod320 preset (as described here). When I encoded it using the ipod640 preset, the file took even longer (around 35 seconds or more) to start playing.
My colleagues report to me that this did not used to be the case, so something has changed. Are we somehow using a non-optimal format for uploading the file? Is there some way for it to be streamed that starts much faster? I note that the sample files provided by wowza begin in 6-9 seconds. This still seems a little too slow for our liking. Those links are structured differently from this, though, without the playlist.m3u8 - I haven’t been able to find out how to make our media stream match this approach, nor work out what exactly is different.
My understanding is that the EC2 build for Wowza is already tuned and optimized so I can’t work out what else we could do, unless I’m missing something! Any advice very gratefully received.
I don’t think chunk count has any affect on latency. Focus on cupertinoChunkDurationTarget and the stream’s key frame frequency.
Richard