HLS使用S3进行流媒体直播 - 这些假设是否正确？

Question

我想制作一个直播视频流。而且，我想使用HLS。

据我所知，HLS实时流只是一个带有'.m3u8'扩展名的主播放列表文件，它列出了所有要播放的文件。

但是，用于直播的，因为所有的文件不可用容易，他们是因为他们进来补充。

我想使用S3现在举办这些文件和播放列表文件。

现在，我想更新S3中的播放列表文件。但它实际上将取代现有的播放列表文件，而不是仅仅更新它（根据this answer）。

所以，我假设在文件替换期间不会有死区。如果有死亡时间，我该如何克服它？这是做到这一点的方式，还是有其他更好的方法来做到这一点。

我正在使用NodeJS服务器，仅供参考。

*没有文件时的死区时间。

Answer 1

我想做一个直播流。而且，我想使用HLS。

为什么选择HLS？为什么不DASH？ DASH也被分割和实现，几乎与HLS完全一样，但是就编解码器的选择而言它具有更多的灵活性，而不是。要么是没问题，但如果你今天从头开始，我推荐使用DASH，以及使用媒体源扩展的DASH.js参考播放器代码。

据我所知，HLS实时流只是一个扩展名为“.m3u8”的主播放列表文件，其中列出了所有要播放的文件。

正确。

但是，用于直播的，因为所有的文件不可用容易，他们是因为他们进来补充。

正确的。

现在，我想更新S3中的播放列表文件。但它实际上将取代现有的播放列表文件，而不是仅更新它

是的，正如其他答案指出的那样，没有区别。播放列表文件将被新的完整副本覆盖。 S3 API不允许附加到文件，除非进行多部分上传，这实际上不是同一件事。无论如何，直播的播放列表文件无论如何都不会包含每个片段。通常你只保留播放列表中的最后一部分片段，但这取决于你决定要走多远。

所以，我假设在文件替换期间不会有死区。

在上传并存储完整的新对象之前，S3不会替换该对象。永远不会有部分文件存在的情况。 S3不像普通的文件系统。另外，如果后续上传失败，旧对象仍将保留。

HLS和DASH播放器在播放前读取播放列表并缓冲大量数据。 （这就是为什么他们出现了严重的延迟问题）。新段上传并添加到播放列表需要几秒钟的时间，因此重要的是他们已经在缓冲区中播放了数据。这就是为什么你不必担心任何退出，除非没有及时上传失败。

我正在使用NodeJS服务器，仅供参考。

是这样吗？听起来你正在使用S3给我...不知道Node.js与这些有什么关系。