Mao*_*ion 9 ffmpeg live-streaming node.js mpeg-dash dash.js
我们正在开发一款应用程序,可以实时监控您的后院。每个客户端都有一个连接到互联网的摄像头,流式传输到我们的公共 node.js 服务器。
我正在尝试使用 node-media-server 发布一个 MPEG-DASH(或 HLS)流,以便我们的应用程序客户端在世界各地的不同网络、带宽和分辨率上可用。
我们的目标是尽可能接近“实时”生活,以便您可以立即监控后院发生的事情。
已经完成的技术流程是:
我们服务器上的 ffmpeg 进程处理传入的相机流(每个相机的单独子进程)并通过本地机器上的 RTSP 发布流以供节点媒体服务器用作“输入”(我们还保存分段文件,生成缩略图等)。负责的 ffmpeg 命令是:
-c:v libx264 -preset ultrafast -tune zerolatency -b:v 900k -f flv rtmp://127.0.0.1:1935/live/office
node-media-server 正在使用我发现的“实时流媒体”的默认配置运行
private NMS_CONFIG = {
server: {
secret: 'thisisnotmyrealsecret',
},
rtmp_server: {
rtmp: {
port: 1935,
chunk_size: 60000,
gop_cache: false,
ping: 60,
ping_timeout: 30,
},
http: {
port: 8888,
mediaroot: './server/media',
allow_origin: '*',
},
trans: {
ffmpeg: '/usr/bin/ffmpeg',
tasks: [
{
app: 'live',
hls: true,
hlsFlags: '[hls_time=2:hls_list_size=3:hls_flags=delete_segments]',
dash: true,
dashFlags: '[f=dash:window_size=3:extra_window_size=5]',
},
],
},
},
Run Code Online (Sandbox Code Playgroud)
};
据我了解,开箱即用的 NMS(节点媒体服务器)以多种输出格式发布它获得的输入流:flv、mpeg-dash、hls。对于这些格式的各种在线播放器,我可以使用本地主机上的 url 访问和流。使用 mpeg-dash 和 hls,我得到了 10-15 秒的延迟,甚至更多。
我现在的目标是实现一个本地客户端 mpeg-dash 播放器,使用 dash.js 并将其配置为尽可能接近生活。
我的代码是:
private NMS_CONFIG = {
server: {
secret: 'thisisnotmyrealsecret',
},
rtmp_server: {
rtmp: {
port: 1935,
chunk_size: 60000,
gop_cache: false,
ping: 60,
ping_timeout: 30,
},
http: {
port: 8888,
mediaroot: './server/media',
allow_origin: '*',
},
trans: {
ffmpeg: '/usr/bin/ffmpeg',
tasks: [
{
app: 'live',
hls: true,
hlsFlags: '[hls_time=2:hls_list_size=3:hls_flags=delete_segments]',
dash: true,
dashFlags: '[f=dash:window_size=3:extra_window_size=5]',
},
],
},
},
Run Code Online (Sandbox Code Playgroud)
使用在线测试视频(https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd)我看到实时延迟值接近 2 秒(但我无法实际确认它。这是一个视频文件流式传输。在我的办公室里,我有一个摄像头,所以我实际上可以比较现实生活和我得到的流之间的延迟)。但是,在本地使用我的 NMS 时,该值似乎不想低于 20-25 秒。
难道我做错了什么?我忘记了播放器(客户端 html)上的任何配置?或者我应该在服务器端(NMS)添加缺少的配置?
HLS 和 MPEG DASH 作为标准延迟并不是特别低,您得到的数字并不罕见。
公开可用的 DASH 论坛文档(链接如下)中的一些示例包括:
鉴于其中一些组织的资源,您取得的成果还不错!
目前流媒体行业非常关注实现更低的延迟,目标是尽可能接近传统的广播延迟。
分块自适应比特率(ABR,请参阅此答案了解更多信息:https : //stackoverflow.com/a/42365034/334402)延迟的一个关键组成部分是播放器需要接收和解码一个或多个片段视频在它可以显示之前。传统上,播放器必须先接收整个片段,然后才能开始解码和显示它。下面第一个链接的开源参考中的图表说明了这一点:
低延迟 DASH 和 HLS 利用 CMAF,即“通用媒体应用程序格式”,它将段(例如,可能是 6 秒长)分解为每个段内的较小“块”。这些块旨在允许播放器在收到完整片段之前解码并开始播放它们。
典型的实时流中的其他延迟来源包括从一种格式到另一种格式的任何转码,以及流媒体服务器从网络摄像头接收提要的任何延迟,以及对其进行编码和打包以进行流媒体传输。
目前有很多关于低延迟流媒体的好信息来自标准机构和开源讨论,我认为这将真正帮助您了解这些问题(在撰写本文时所有链接都是最新的)。来自开源和标准讨论:
来自供应商:
注意 - 广播界经常引用的一个常见用例是,观看比赛等现场赛事的人可能会在他们自己看到之前听到他们的邻居庆祝进球或达阵,因为他们的饲料比他们的邻居有更高的延迟。虽然这是低延迟的驱动因素,但这确实是一个同步问题,如果目标是“完美”同步解决方案,则需要其他解决方案。
正如您所看到的,低延迟流式传输不是一个简单的挑战,您可能需要根据用例的详细信息考虑其他方法,包括您拥有多少订阅者,如果公平权衡是否会造成一些质量损失更低的延迟等。正如@user1390208 在评论中所提到的,像 WebRTC 这样更实时的视频通信技术可能更适合您所针对的解决方案。
如果您想提供既提供生活流媒体又提供录音的服务,您可能需要考虑使用实时协议进行实时流媒体视图和 HLS/DASH 流媒体,以便任何人回顾录音,其中延迟可能不重要但质量很重要可能更关键。