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

Question

我正在努力快速学习HDS和HLS实时流媒体背后的一些基础技术.

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

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

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

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

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

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

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

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

感谢您提供的任何见解!

Answer 1

有没有办法为媒体配置不同的站点名称？对于 DVR 会话，您希望直接从服务器提供 m3u8 文件（无 CF，或 2 秒 CF），但通过 CloudFront 提供媒体文件，且过期时间非常长。

（对于非 DVR 会话，它可以全部通过 CloudFront，因为它是可缓存的。）

CloudFront 的实用性实际上取决于您拥有多少受欢迎（和不受欢迎）的流。

例如，假设某个特定 POP 中有 20 个 CloudFront 盒子。如果 5 个人观看一个流，则每个人都可能会访问不同的 CF 盒，出现缓存未命中情况，并且无论如何都需要访问您的服务器。在 CloudFront 停止访问您的服务器并通过缓存提供所有内容之前，您必须有 50 或 70 人查看来自该 POP 的流。因为有很多 POP，所以可能有 100 个人在世界各地观看流，但每个人都访问不同 POP 中的不同盒子，而您的服务器仍然会收到 100 个请求。