HLS与S3直播 – 这些假设是否正确?

我想做一个直播。 而且,我想用HLS。

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

但是,对于直播,因为所有的文件都不容易获得,所以他们在进来时被添加。

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

现在,我想更新S3中的播放列表文件。 但它实际上将取代现有的播放列表文件,而不是只更新它(根据这个答案 )。

所以,我假设文件replace期间不会有死机。 如果有一个死亡时间,我该如何克服呢? 这是做到这一点的方式,还是有其他更好的方法来做到这一点。

我正在使用一个NodeJS服务器,只是FYI。

*没有文件时的死时间。

我想做一个直播。 而且,我想用HLS。

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

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

正确。

但是,对于直播,因为所有的文件都不容易获得,所以他们在进来时被添加。

正确。

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

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

所以,我假设文件replace期间不会有死机。

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

HLS和DASH播放器在播放之前读取播放列表并缓冲大量数据。 (这就是为什么他们有很高的延迟)。新段上传并添加到播放列表之前需要几秒钟的时间,所以重要的是他们已经有数据在缓冲区中播放。 这就是为什么你不必担心退出,除非没有及时上传失败。

我正在使用一个NodeJS服务器,只是FYI。

是这样吗? 听起来像你使用S3给我…不知道什么Node.js必须做任何这一点。