Hi there ... I'm wondering if you have a best practice document for streaming out of EC2 instance as origin, Cloudfront and using S3 buckets
I have the workflow working fine, but the startup time of a VOD playback is more than 6 seconds, which I consider extremely high.
I'd like to know if you have best practices to remove this latency
Does Wowza starts serving the video as soon as it have some content, or it requires to have access to all content in memory before it serves it out?
Thanks in advance
Note: when video is cached, startup is not that high ... but sometimes people don't watch all content, so not all content is cached, and when you fast forward, again it takes more than 6 secs to playback
There are possibly a few causes for the issues you are seeing and there are some tests that you can do to see where the problem is.
The issue may be with the delivery time between S3 and Wowza or between Wowza and the CloudFront server. Bot Wowza and the CloudFront server will be caching the content so it will get quicker as it is cached closer to you.
First, confirm if the CloudFront server is causing the initial delay. To do this, stream a file via CloudFront from a regular VOD application that isn't HTTP Origin or MediaCache enabled. eg: sample.mp4 from the default VOD application. Because it isn't HttpOrigin enabled, Wowza will attach session id's to the requests which will prevent CloudFront from caching it and the file will already exist on the Wowza server so it will be as if it was already cached from S3 by Media Cache.
If the load time is slow, try streaming the same file directly from the Wowza server application. If the CloudFront stream is a lot slower to load than the direct stream then it is the network between CloudFront and the EC2 server that is causing the delays and there isn't a lot that can be done apart from possibly making the segment sizes smaller so that they are retrieved quicker.
To do this, there is are properties that can be set in the application configuration that controls the target segment size. The default is 10 second segments and we have found some improvements with lowering this value to create smaller segments which will download quicker, allowing the stream to start quicker and seek quicker. The target duration should be multiples of the Key Frame interval however if it doesn't match exactly, Wowza will make the actual segment sizes to the closest key frame.
Apple HLS default 10000 (10 seconds)
Adobe HDS default 10000 (10 seconds)
Run the same test with an application that is HttpOrigin enabled (but not Media Cache enabled) and compare the results. This one will get cached by CloudFront so you should expect to see an improvement after the stream is initially cached.
If you don't see any improvements here then check the load time between Wowza and S3. To do this, you will need to enable http request debug logging in your Media Cache Source configuration. Add the following property to you Media Cache Source properties. You will have to restart Wowza after changing the properties and don't forget to disable it when you have finished testing.
Debug HTTP requests between Wowza and Media Cache source
You will need to examine the Wowza log files and when a stream is requested, you should see a bunch of requests to the Media Cache which will be grouped together. Each group will be a single segment and you will be looking at the time taken for all of the requests for a segment to return. What we have generally found is that the request only take a few milliseconds to return so this may not be the cause of the delays.
You may see some improvement by increasing the
defaultBlockSize setting in the Media Cache Source configuration. This will make less (but larger) requests for each segment and allow S3 to better utilize the bandwidth between S3 and Wowza.
When testing caching, you may need to flush the item from the cache each time or restart Wowza to flush it.
Don't forget to transfer any settings to your production application.