S3直播-这些假设是正确的吗？

Question

我想做一条活生生的小溪。我想用HLS。

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

但是，对于实时流来说，由于所有的文件都不是随时可用的，所以当它们进来时就会添加它们。

我现在想使用S3来托管这些文件和播放列表文件。

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

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

我使用的是NodeJS服务器，只是FYI。

*没有文件的死区时间。

Answer 1

我想做一条活生生的小溪。我想用HLS。

为什么是他？为什么不达什？破折号也是分割和实现几乎完全相同的HLS，但有更多的灵活性，就编解码器的选择和什么不是。这两种方法都可以，但如果您今天从头开始，我推荐DASH，以及使用Media扩展的DASH.js参考播放器代码。

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

对，是这样。

但是，对于实时流来说，由于所有的文件都不是随时可用的，所以当它们进来时就会添加它们。

对，是这样。

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

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

所以，我假设在文件替换过程中不会有死时间。

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

HLS和DASH播放器在开始播放前会读取播放列表并缓冲大量数据。(这就是为什么它们有很高的延迟。)在上传新段并将其添加到播放列表之前，需要几秒钟的时间，所以重要的是，它们已经有了缓冲区中的数据可供播放。这就是为什么你不必担心任何辍学，除非有一个未能及时上传。

我使用的是NodeJS服务器，只是FYI。

是真地吗？听起来你在用S3 .不知道Node.js和这一切有什么关系。