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》说到使用了CGO实现的内置音频实时转码器。开发中遇到一个很严重的问题:无法直接生成跨平台可执行程序了。

首选我们了解到,Go语言是可以在开发平台直接生成多个目标架构和系统的可执行程序。只需要在编译前指定GOOS和GOARCH,便可以直接生成目标文件。

但当使用了CGO,便失去了这种能力。在本机平台以外,需要设置CGO_ENABLED,并且指定CC. linux和macos还好,windows也是需要gcc工具链,这个就需要部署MinGW等很复杂的操作。

在多次尝试后,受到这个项目的启发,编写了一个更简单的xcgo docker image.

继续阅读

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

本文链接地址: XCGO:CGO的跨平台编译器

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

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

继续阅读

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

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

今天接到一个客户的需求,在不改变原有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转码服务

In other news, GStreamer is now almost buzzword-compliant! The next blog post on our list: blockchains and smart contracts in GStreamer.

Late last year, we at Centricular announced a new implementation of WebRTC in GStreamer.  Today we’re happy to announce that after community review, that work has been merged into GStreamer itself! The plugin is called webrtcbin, and the library is, naturally, called gstwebrtc.

The implementation has all the basic features, is transparently compatible with other WebRTC stacks (particularly in browsers), and has been well-tested with both Firefox and Chrome.

Some of the more advanced features such as FEC are already a work in progress, and others will be too—if you want them to be! Hop onto IRC on #gstreamer @ Freenode.net or join the mailing list.

How do I use it?

Currently, the easiest way to use webrtcbin is to build GStreamer using either gst-uninstalled(Linux and macOS) or Cerbero (Windows, iOS, Android). If you’re a patient person, you can follow @gstreamer and wait for GStreamer 1.14 to be released which will include Windows, macOS, iOS, and Android binaries.

The API currently lacks documentation, so the best way to learn it is to dive into the source-tree examples. Help on this will be most appreciated! To see how to use GStreamer to do WebRTC with a browser, checkout the bidirectional audio-video demos that I wrote.

Show me the code! [skip]

继续阅读

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

本文链接地址: [转] GStreamer has grown a WebRTC implementation

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

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

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

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

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

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

  • 小程序不会对写入数据包大小做限制,但系统与蓝牙设备会限制蓝牙4.0单次传输的数据大小,超过最大字节数后会发生写入错误,建议每次写入不超过20字节。

可能你已经在用小程序开发BLE应用了,也遇上了这个问题,我这儿是一种写法,并不限于这一种,仅供参考

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

本文链接地址: 微信小程序蓝牙BLE发送数据包大于20字节的写法

最近做一款Android与蓝牙BLE设备通讯的项目,记录下开发经验。

蓝牙设备是JDY-19模块,串口透传,非常方便好用。官方教程需要创建Service进行通讯,此处需求为简单数据透传,直接在Activity中收发完成就结束,不开启服务,简单便捷。话不多说,代码伺候。

一、Android扫描BLE设备

0. 开启权限

1. 检查是否有BLE支持

2.检查是否有蓝牙支持

继续阅读

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

本文链接地址: Android BLE通讯详解,连接JDY-19

一般我们调试Firebreath的插件,使用的方法是,启动一个老版本的firefox(单进程),打开插件页面后,在调试中选择“附加到进程”,选择firefox进程,触发断点调试。

但有的时候需要调试启动过程,那么这个方法就不行了。
其实直接按F5启动调试的办法也很简单,只需设置“ALL_BUILD属性”,在“配置属性”-》“调试”中。
命令输入firefox.exe的全路径,命令参数输入插件的html地址,可以是本地文件路径,就行了。

如果dll注册就在debug生成目录,那么不需要额外操作,直接就能开始调试了。

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

本文链接地址: 如何在Visual Studio 中,F5启动调试Firebreath插件

这是困扰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直播