使用Wowza 3.5在Amazon CloudFront中缓存HLS / HDS流

时间:2012-12-07 13:40:59

标签: amazon-web-services http-live-streaming amazon-cloudfront live-streaming wowza

我正在努力快速学习HDS和HLS直播的一些基础技术。

我在EC2中的Amazon WebServices实例上设置了Wowza Media服务器3.5,并通过CloudFront分发。我做了我的第一次直播活动,并且正在观察我的服务器负载越来越高。我想知道是否有人可以帮助我理解HDS / HLS直播(和nDVR ......)的一些基础:

  • Wowza是我的云端分发的原始服务器
  • HDS清单文件设置为以CF(TTL时间)
  • 缓存2秒
  • 我检查了所有触及我的Wowza实例的IP,它们实际上是CF缓存位置或边缘服务器
  • (假设)由于所有HDS流量都超过端口80,所有视频内容最终都会缓存在边缘位置(尽管持续2秒)。

以下是我的问题:如何为视频内容提供数据(这是我的理解,请让我直截了当!):   - 当观众请求播放列表或主要节日文件时,他们会返回XML,将播放器指向一个视频/音频块(DVR应用程序实例中的m4fa和m4fv?)下一个需要播放的数据。由于此数据也通过端口80传递,因此它也被缓存。

如果上述陈述是正确的,那么以下内容对于HDS和HLS的优化是否有意义:

案例1:DVR服务: 我在CloudFront中设置了缓存规则,如下所示:

  • 以“f4m”,“m3u8”和“?DVR”结尾的任何内容,缓存2秒(播放列表/清单文件)
  • 其他一切的默认值应该缓存更长时间(也许一小时,或24小时......?) 这样,DVR数据仍然被缓存,但播放列表每2秒更新一次

案例2:没有DVR服务(这是更好的优化方式吗?)

  • 我怀疑我们可以通过一起杀死DVR服务来优化服务器负载,这样通过CF分发的所有数据都只是最新的音频/视频数据包 - 因此所有观众都应该请求相同的播放列表和数据文件,因此,大量请求这些文件的人没什么大不了的,因为我的服务器每两秒钟就会从每个边缘位置被点击以更新清单文件。)
  • 如果媒体文件块的缓存时间较长,如果媒体仍然被缓存,我们是否会杀死DVR服务?

感谢您提供的任何见解!

1 个答案:

答案 0 :(得分:2)

有没有办法为媒体配置不同的网站名称?对于DVR会话,您希望m3u8文件直接从您的服务器提供(无CF或2秒CF),但是通过CloudFront提供的媒体文件的到期时间非常长。

(对于非DVR会话,它可以全部通过CloudFront,因为它可以缓存。)

CloudFront的实用性取决于您拥有多少流行(和不受欢迎)的流。

例如,假设特定POP中有20个CloudFront框。如果有5个人查看流,则每个人都可能会遇到不同的CF框,无法获取缓存并且无论如何都需要访问您的服务器。在CloudFront停止访问您的服务器并从缓存中提供所有内容之前,您必须有50或70人从该POP查看流。由于有许多POP,您可以让100个人在全球范围内查看流,但每个人在不同的POP中点击不同的框,并且您的服务器仍然会收到100个请求。