NMS v3系列教程之 八、relay规则鉴权模板

模板说明

创建relay中继任务,实际上就是rtmp的play或publish操作。
当我们连接远端服务器时,对方可能开启了鉴权规则,那么我们的链接也必须要附带鉴权参数。
由于目前常用的鉴权方式是附带过期时间戳的,因此每次请求时都应该是不同的签名。
当然您也可以预生成一个过期时间特别久的比如1年以后过期。
使用nms的relay规则,可以在创建时填入签名参数的模板,在nms进行relay中继任务创建时根据模板生成新的签名参数。

模板例子

nms模板

讲解:
前面我们的鉴权算法中有说明到,生成签名前的字符串需要流信息+过期时间+密码后md5
上面的模板字符串可以分为3个部分

继续阅读“NMS v3系列教程之 八、relay规则鉴权模板”

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: NMS v3系列教程之 八、relay规则鉴权模板

NMS v3系列教程之 七、从NVR\IPC拉取监控画面

需求简介

目前使用监控摄像头可以做非常多的行业应用,我们的客户案例中,涵盖了幼儿园监控手机直播,远程课堂直播,重点监控单位中心监控与手机监控,抓娃娃机,宠物监控远程喂食,甚至还有远程投币祈福等等等等,没有做不到只有想不到。
而传统监控摄像头统一的协议标准是RTSP,而直播行业目前统一的标准是RTMP。要将两者结合起来最简单的方式,是通过ffmpeg命令输入rtsp,输出rtmp。将视频流分发到自建服务端或者直播云服务,再由各个客户端根据需求播放rtmp或在http-flv。
这种方式需要解决如下问题

  1. rtsp流地址生成与通道管理,各个厂商之间的流地址格式是不同的
  2. 进程调用的维护,错误处理与断线重连问题
  3. 原生rtmp协议不支持监控行业日益流行的H265视频
  4. 部分云服务和web客户端不支持监控设备常见的G.711音频

解决方案

  • NMS内置了一个Relay中继模块,可以通过web后台简单添加rtsp拉取任务,无需编写配置文件,无需重启服务。
  • 目前支持海康,大华,宇视直接配置参数创建拉取任务,后续会增加其他厂商的规则,如果您是监控厂商,想要在NMS中增加品牌RTSP规则,请直接与我们的商务服务联系。
  • 也支持自定义模式手动输入rtsp地址和rtmp地址。
  • 任务创建后,服务会立刻去执行,并且在web后台反馈状态信息。relay任务也会在输入或输出中一项断开后自动重连,并将relay任务写入本地数据库,在nms服务程序重启后继续执行,直到任务被删除。
  • relay模块支持H265编码推拉流,NMS也支持h265编码的RTMP协议

使用方法

继续阅读“NMS v3系列教程之 七、从NVR\IPC拉取监控画面”

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: NMS v3系列教程之 七、从NVRIPC拉取监控画面

NMS v3系列教程之 六、直播鉴权

NMS内建支持简单且非常安全的,基于密码和过期时间的鉴权模式。
与阿里云的直播鉴权模式比较类似。

开启方法

打开config.ini

鉴权密码

播放鉴权开关

0-关闭,1-打开

推流鉴权开关

0-关闭,1-打开

使用方法

继续阅读“NMS v3系列教程之 六、直播鉴权”

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: NMS v3系列教程之 六、直播鉴权

NMS v3系列教程之 五、事件通知

功能简介

NMS支持在服务端收到流开始播放,结束播放,开始推流,结束推流时回调一个web服务接口。
可作为后台管理程序进行自定义鉴权,统计推流播放信息包括ip,开始结束时间,url参数,使用流量等。

开启方法

打开config.ini文件,取消notify_url前的注释,填上接收回调的web api地址。
如:

简单用例

我们使用nodejs创建一个简单的web api接口,并打印接收到的信息

继续阅读“NMS v3系列教程之 五、事件通知”

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: NMS v3系列教程之 五、事件通知

NMS v3系列教程之 四、后台管理

打开后台程序

程序运行后,可通过浏览器访问 http://server_ip:8000/ 访问nms管理后台

登陆

当配置文件项 auth_api 开启并且正确设置了auth_api_user和auth_api_pass,第一次打开管理后台页面时,需要进行登陆。

继续阅读“NMS v3系列教程之 四、后台管理”

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: NMS v3系列教程之 四、后台管理

NMS v3系列教程之 三、基本使用

nms直接运行后,可以看到控制台输出打印

可以看到 rtmp服务绑定1935端口,http和https端口分别是8000和8443

1935作为rtmp的默认端口,可以在使用时不填写,比如

8000端口作为http-flv和websocket-flv端口,需要跟上端口号和.flv后缀

API接口和管理后台复用8000和8443端口,浏览器直接访问web后台

http://server_ip:8000/

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: NMS v3系列教程之 三、基本使用

NMS v3系列教程之 二、下载安装

Windows版

https://nodemedia.oss-cn-hangzhou.aliyuncs.com/nms/3.1.15/nms-windows-amd64-20191211.zip

  • 解压缩后双击运行nms.exe
  • 双击service.bat 安装为服务并自动运行
  • 在当前目录打开控制台输出 service.bat uninstall 停止并卸载服务

Linux x86_64 版

https://nodemedia.oss-cn-hangzhou.aliyuncs.com/nms/3.1.15/nms-linux-amd64-20191211.tar.gz

  • 解压缩后进入目录,在控制台输入 ./nms 运行
  • 在当前程序目录下执行 sudo ./service.sh install 安装服务并自动运行
  • 在当前程序目录下执行 sudo ./service.sh uninstall 停止并卸载服务

Linux arm64 版

https://nodemedia.oss-cn-hangzhou.aliyuncs.com/nms/3.1.15/nms-linux-arm64-20191211.tar.gz

Mac版

https://nodemedia.oss-cn-hangzhou.aliyuncs.com/nms/3.1.15/nms-darwin-amd64-20191211.tar.gz

  • 解压缩后进入目录,在控制台输入 ./nms 运行

Docker版

docker run -it —name nms -p 1935:1935 -p 8000:8000 -p 8443:8443 illuspas/nms

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: NMS v3系列教程之 二、下载安装

NMS v3系列教程之 一、简介

Node Media Server 以下简称nms,最初是以node.js实现的RTMP协议流媒体服务端。
最新v3版使用go语言重写了整个项目,获得了更好的并发性能,也拥有了更强的功能。

特性

  • 支持多核,万级并发
  • 支持Windows/MacOS/Linux
  • 支持X86_64/ARM64架构
  • 支持Rtmp/Http-FLV/Websocket-FLV/JT-T1078协议接入
  • 支持Https/Wss加密协议接入
  • 支持H.264,H.265视频编码
  • 支持AAC,Speex,NellyMoser,G711音频编码
  • 支持非AAC编码推流时,零延迟转码AAC
  • 支持web后台快捷添加海康、大华、宇视RTSP拉流转发
  • 支持配置自定义RTSP、RTMP地址拉取转发
  • 支持拉流转发任务持久化存储
  • 支持拉流转发任务断线自动重连
  • 支持创建转推拉规则时基于go模板方式的自定义鉴权参数(可支持nms,阿里云,腾讯云等鉴权规则)
  • 支持详细数据统计
  • 支持Gop_Cache
  • 支持管理型后台程序
  • 支持流状态http回调
  • 支持规则转推,多路push
  • 支持规则转拉

计划

  • 支持低延迟HLS – v3.2
  • 支持WebRTC协议 – v3.2
  • 支持GB28181协议 – v3.3
  • 支持kcp-flv超低延迟,弱网满速传输 – v3.4
  • 支持MIPS64EL,armv7架构
  • 替换Nodelayer.js作后台视频预览播放器,以支持H.265视频

文档

http://www.nodemedia.cn/doc/web/#/5

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: NMS v3系列教程之 一、简介

用Go语言开发的新版NodeMediaServer

之前曾介绍过一款用Node.JS实现的开源RTMP流媒体服务端。目前更新到2.1.3版本,这是个从15年出开始接触Node.js作为研习而建立的项目。说起写完这个项目,对理解nodejs异步架构,rtmp网络协议还是起到了非常重要的作用。

rtmp协议如果用异步解析数据还是比较麻烦的,最早的版本写了个buffer缓冲,再用Generators/yield来转成同步逻辑,简单了许多。接触到async、await后又更新了个版本,代码可读性提高了不少。最后又学习了一个异步状态机的实现,比较满意。

继续阅读“用Go语言开发的新版NodeMediaServer”

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: 用Go语言开发的新版NodeMediaServer

重写了Node.js版的Node-Media-Server

第一次尝试用Node.js实现RTMP服务器是在15年初的时候,那时候刚完成Android/iOS平台上rtmp播放发布SDK:NodeMediaClient的雏形.
那时候有个参考项目https://github.com/iizukanao/node-rtsp-rtmp-server,当时的完成度算是比较高的了(Node.js实现) ,不过作者很牛,是用coffee-script实现的,基本看不懂,转译后的js代码也比较难读.
另外这个项目最大的问题是RTMP协议包解析,性能非常低.如果你单推一个1080的视频,cpu直接起飞,还不说播放.
这倒不怪作者,Node.js这种异步回调的模式,处理RTMP这种复杂数据包非常不利.
而我使用的解决方法是用到ES6的Generators+stream,封装为一个bufferpool.
socket异步回调数据的时候,往bufferpool里填数据,解析线程(这里也可能应该叫协程)先尝试询问是否有足够的数据,不够就yield,将CPU让给其他处理,当异步回调继续push数据时,如果达到上次需求的数据量,cpu就跳到刚刚yield的协程处继续往下解析.
仍然是单线程事件驱动,但数据解析是同步的逻辑.

发送逻辑暂时是用emit事件去通知socket发送data,可能比直接发送要多费些cpu,后面的版本继续优化.

也不限制音频编码了,以前的版本只支持H.264/AAC这种组合,现在speex,nellymoser也支持.

直播中首屏启动速度也是非常重要的,以前都叫秒开,现在得叫毫秒开.其实很关键的技术就是除了第一帧的sps/pps,紧接着就得来一个视频关键帧.
播放时当然不是每次都遇到第一个视频关键帧,所以得把推流端最近的关键帧缓存起来,播放时先把缓存的关键帧推下去.
就是GOPchache啦,nginx-rtmp还没有这个功能,体验还比不上SRS.
Node-Media-Server当然也支持啦,缓存最近的一个GOP.而且在Nodejs中实现也是非常非常简单的,这里就不多讲了,看代码吧.
当然就有人说有GOP缓存,延迟就大了,这是对的.不过自己实现播放端的话,还是很容易通过播放队列的长度来进行快进播放或丢弃处理,这样首屏毫秒开,延迟也可以自由控制.NodeMediaClient里,NodePlayer播放类就有两个参数,bufferTime和maxBufferTime.既保证首屏好秒开,又保证视频延迟低.

另外这次重写也新学了ES6的一些新特性和规范,代码写起来也比较规范吧.

后面可能还会继续实现其他的一些功能像是http-flv,hls,录制,转推,多进程这些硬性要求
也可能会实现Server Application,RTMPE,WebSocket,ffmpeg转码等
也或者支持接入WebRTC流,RTMFP等

项目地址:https://github.com/illuspas/Node-Media-Server
国内镜像:https://gitee.com/illuspas/Node-Media-Server

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: 重写了Node.js版的Node-Media-Server