从 SRS 如何传输 HLS wiki ,我们知道SRS在hls_path中生成相应的M3U8播放列表,这是我的配置文件:
http_server {
enabled on;
listen 8080;
dir ./objs/nginx/html;
}
vhost __defaultVhost__ {
hls {
enabled on;
hls_path /data/hls-records;
hls_fragment 10;
hls_window 60;
}
}
在一个 SRS 服务器情况下,每个播放 HLS 流的客户端都访问同一个推送 SRS 服务器,这是可以的。但在origin集群模式下,有很多SRS服务器,每个流都在其中一台。当客户端播放此 HLS 流时,我们无法保证它可以访问正确的原始 SRS 服务器(如果不存在,则会导致 404 http 状态代码)。与 RTMP 和 HTTP-FLV 流不同,SRS 通过 HTTP-API 功能使用同事来重定向正确的源 SRS。
为了解决这个问题,我认为有以下两种解决方案:
- 使用专门的后端 HLS 分段 SRS 服务器:
不要在原始SRS服务器中生成M3U8,每个流都转发到该SRS服务器,所有M3U8都在此服务器中生成,所有HLS请求都代理到该服务器(使用nginx)。缺点。该方案仅限于一个实例,无扩展能力,存在单节点风险。
the origin srs.conf forward config like this:
vhost same.vhost.forward.srs.com {
# forward stream to other servers.
forward {
enabled on;
destination 192.168.1.120:1935;
}
}
where 192.168.1.120 is the backend hls segment SRS server.
- 使用NFS/K8S PV/分布式文件系统等云存储:
将云存储挂载为每个SRS服务器中的本地文件夹,无论SRS服务器中的流,M3U8文件和ts段都传输到同一个大存储中,因此在HLS请求之后,http服务器将它们作为静态文件提供。从我的测试来看,如果云存储写入速度可靠的话,是一个不错的解决方案。但如果网络抖动或者写入速度不如接收速度,就会阻塞其他协程,导致SRS异常。
The hls_path config like this:
vhost __defaultVhost__ {
hls {
enabled on;
hls_path /shared_storage/hls-records;
hls_fragment 10;
hls_window 60;
}
}
Here 'shared_stoarge' means a nfs/cephfs/pv mount point.
在我看来,上述解决方案并没有从根本上解决访问问题,我期待为这种情况找到更好可靠的产品解决方案?
最佳答案
当您使用 OriginCluster 时,您必须获得大量流来提供服务,有大量编码器将流发布到您的媒体服务器。解决问题的关键:
- 永远不要使用单一服务器,使用集群来获得弹性能力,因为将来你可能会获得更多的流。所以转发不好,因为你必须配置一组特殊的流来转发,类似于手动哈希算法。
- 除了带宽之外,磁盘IO也是瓶颈。您肯定需要一个高性能的网络存储集群。但要小心,千万不要让SRS直接写入存储,它会阻塞SRS协程。
据我所知,最好的解决方案是:
- 使用SRS Origin Cluster,将HLS写入本地磁盘,或者RAM磁盘更好,以确保磁盘IO永远不会阻塞SRS协程(由状态线程网络IO驱动)。
- 使用网络存储集群来存储 HLS 文件,例如 AWS S3 等云存储,或 NFS/K8S PV/分布式文件系统等。使用nginx或CDN来交付HLS。
现在的问题是:如何将数据从内存/磁盘移动到网络存储集群?
您必须通过 Python 或 Go 构建服务:
- 使用
on_hls
回调通知您的服务移动 HLS 文件。 - 使用
on_publish
回调通知您的服务启动 FFmpeg 将 RTMP 转换为 HLS。
Note that FFmpeg should pull stream from SRS edge, never from origin server directly.
关于http-live-streaming - 如何保证在origin集群模式下访问正确的后端M3U8文件,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/70405004/