by ·0评论

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系列教程之 三、基本使用

by ·0评论

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系列教程之 二、下载安装

by ·0评论

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系列教程之 一、简介

by ·3条评论

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

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

继续阅读

原创文章，转载请注明： 转载自贝壳博客

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

by ·0评论

今天接到一个客户的需求，在不改变原有fms服务架构的条件下，对接到Node-Media-Server，提供HLS,RTMP，Http-FLV音频转码服务。

客户以往的架构是Flash在web推流，h.264+Nellymoser编码格式，这个用flash播放是没有问题的

但flash基本上已经被各大浏览器列为默认关闭了，Android，iOS等更是不会支持的。

现在的解决方案，基本上是往HLS，http-flv上靠。HLS提供了最好的兼容性，http-flv提供了最低的延迟性，各有优劣吧。

关键的问题在于，Nellymoser编码并非互联网上广泛支持的格式，就算服务端支持，客户端也基本（有h5客户端支持，后话）上无法实现。

因此，还需要使用ffmpeg进行音频转码。

架构如下：
fms端使用服务端编程，监听 onPublish 和 onUnpublish事件，将参数通过http传参调用。

nms增加api接口收到开始和结束的事件，调起ffmpeg从fms拉流，copy视频，aac编码音频后推到Node-Media-Server。

Node-Media-Server则提供出hls，rtmp，http-flv流。

注：NodePlayer.js 支持web浏览器解码播放Nellymoser，并且兼容各大pc，安卓，iPhone。
需要了解方案详情欢迎与我联系

原创文章，转载请注明： 转载自贝壳博客

本文链接地址: 记一次FMS对接Node-Media-Server转码服务

by ·0评论

前期曾发布过一款windows平台RTMP推送摄像头画面的浏览器插件，近期对这款产品进行了升级，现已支持捕获桌面画面进行推流。

桌面推流当然首选OBS，专业性毋庸置疑。本人开发的这款产品定位为简单业务需求，只需引导客户安装5M左右大小的插件程序，无需任何配置，即可在web网页中进行摄像头或桌面画面的捕获推流。

在本次更新中，加入了H.265编码器的支持，视频码率更低。同时，在SSE指令集加速的软编码基础上，增加了AMD/NVIDIA/INTEL独显核显硬件加速编码，CPU消耗更低。

本插件同时也加入了直播播放器的支持，可以播放rtmp，rtsp，http协议的直播流，并支持硬件加速解码，首屏秒开与延迟消除技术。继续阅读

原创文章，转载请注明： 转载自贝壳博客

本文链接地址: Windows平台浏览器内捕获桌面画面并RTMP推流

by ·一条评论

这是困扰N年的问题了，Adobe似要放弃但又不舍的flash，一直在更新，但大家呼唤已久的aac编码始终不肯加入。
于是基本上需要做高级点Web页直播的，不是让主播用第三方工具，就是在服务端实时转码，挺费劲的。
简单点的基本上全站flash的也有，flash仅做推流播放的也很多。

WebRTC在大家的期盼下也慢慢得到了大部分浏览器的支持，但结果一看这丫也不用aac，而是用的Opus，似乎是个版权问题？
Opus在语音与音乐等编码场景都能应对，但rtmp不支持呀，还是需要转码。协议接入也是一个麻烦点。

既然Adobe能开发flash插件，大家为啥不直接开发插件呢？

这个说起来似乎更痛苦，ie要开发ActiveX，win10 更新到Edge了，又不知道是支持哪种（有了解的朋友请告知我一下）？早先的chrome和firefox要开发NPAPI，现在不兼任了，又要开发PPAPI。
似乎只有大公司能折腾这些事吧。腾讯云好像有一款ActiveX的推流插件，但没仔细看。尽管可以兼容ie，做点行业应用，但你现在让前端做ie兼容的娱乐向页面，他分分钟摔键盘。

最近有一点研究时间了，回看了一下之前了解过的FireBreath,说是可以一次开发多个平台的浏览器插件，我觉得可以利用它来实现我一直想要实现的功能。
1.x版本可以支持ActiveX和NPAPI的插件，2.x说是准备兼容PPAPI，但似乎有点麻烦，这方面资料也不多，而且项目也已经很长时间未更新了。
似乎又陷入绝境。
继续阅读

原创文章，转载请注明： 转载自贝壳博客

本文链接地址: 如何在浏览器里面推送H.264+AAC的RTMP直播

by ·0评论

最近在研究用Emscripten开发JavaScript的直播播放器，使用ffmpeg内置的h264解码速度还是可以接受的，本想使用openh264的解码进行比较，但发现非常慢，无法达到640×480@30帧的解码速度。

本来以前也有过用openh264的项目，直接使用libopenh264进行解码速度还是很快的。但编译进ffmpeg里使用就特别慢，于是-g重新编译NodePlayer.js并开始Chrome Performance录制。
继续阅读

原创文章，转载请注明： 转载自贝壳博客

本文链接地址: ffmpeg.js使用libopenh264解码性能低的原因

by ·一条评论

iOS的浏览器环境，当然就包括微信,QQ内打开。目前实现直播的协议一般都是HLS, 延迟大可想而知，“真·实时” 当然指的是2秒以内的延迟。

浏览器环境下支持常见的低延迟直播，首选的是flv.js。它支持多种数据获取方式（fetch，websocket，xhr），兼容性很好。解析flv流后再封装为mp4数据，使用Media Source Extensions 特性，将数据投喂给播放器以实现实时的解码播放。按浏览器支持情况，具有硬件加速的性能。

而iOS是目前无法实现的平台，https://caniuse.com/#search=mediasource 可以看到，到目前为止系统11.2仍然不支持该特性。

但通过websocket+WebAssembly技术，可以曲线救国。我已经实现了一个初版https://github.com/illuspas/NodePlayer.js
继续阅读

原创文章，转载请注明： 转载自贝壳博客

本文链接地址: 如何在iOS的浏览器环境内实现 “真·实时视频播放”

by ·0评论

重采样

Hi35xx 的音频输入和音频输出模块支持对音频数据实施重采样。如果启用 AI 重采样功 能，则在 HI_MPI_AI_GetFrame 获取数据返回前，内部将会先执行重采样处理，再返 回处理后的数据。如果启用了 AO 重采样功能，则音频数据在发送给 AO 之前，内部 先执行重采样处理，处理完成后再发送给 AO 通道进行播放。

音频重采样支持任意两种不同采样率之间的重采样。重采样支持的输入输出采样率 为:8kHz，11.025kHz，12kHz，16kHz，22.05kHz，24kHz，32kHz，44.1kHz， 48kHz。

  • 当 AI-AENC 或 AI-AO 的数据传输方式为系统绑定方式时，AI 或 AO 的重采样无效
  • 非系统绑定方式下，用户可以通过 HI_MPI_AI_GetFrame 接口获取重采样处理后的 AI 音频帧，并发送给 AENC/AO，以建立 AI-AENC 或 AI-AO 的数据传输，此时 AI 或 AO 的重采样有效。
  • ADEC-AO的数据传输方式无上述限制，当为系统绑定方式时，AO的重采样仍有 效。

当你使用hi35xxx_enc.cpp提供的方法来开发时,实际上重采样功能是无法实现的,因为在StartAenc方法里,AI->AENC是通过系统绑定的方式(HI3516A_COMM_AUDIO_AencBindAi)关联的,如果需要重采样功能,这个地方应该使用(HI3516A_COMM_AUDIO_CreatTrdAiAenc).
这个函数创建了一个线程,先从AI(HI_MPI_AI_GetFrame)里获取数据,再发送给AENC(HI_MPI_AENC_SendFrame),然后释放(HI_MPI_AI_ReleaseFrame),这时从AENC里取回(HI_MPI_AENC_GetStream)的数据,才是重采样后的数据. 当然,这一切的前提是需要HI_MPI_AI_EnableReSmp,并正确传入输入与输出采样.

原创文章，转载请注明： 转载自贝壳博客

本文链接地址: 海思 HiMPP-IPC 媒体处理平台开发参考阅读笔记 二