前段时间Chrome自动升级到60.0.3112.90后，突然发现Flash无法访问摄像头麦克风了，不管是曾经设为信任的域名还是新域名，Chrome都不再弹出是否允许访问摄像头麦克风的提示框，这在59版本上都不存在的问题。
情况如图所示： 继续阅读“Chrome更新到60以后，Flash无法再继续访问摄像头麦克风？”
原创文章，转载请注明： 转载自贝壳博客
重写了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
使用MSYS2编译Windows平台FFmpeg问题集合
1.安装了speex但找不到
|
1 |
ERROR: speex not found using pkg-config |
|
1 |
pacman -S pkg-config |
2.configure 配置完以后提示找不到cmp命令
|
1 2 3 4 5 6 |
Creating configuration files ... ./configure: line 1424: cmp: command not found ./configure: line 1424: cmp: command not found ./configure: line 1424: cmp: command not found ./configure: line 1424: cmp: command not found ./configure: line 1424: cmp: command not found |
|
1 |
pacman -S diffutils |
……后续继续补充
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: 使用MSYS2编译Windows平台FFmpeg问题集合
适用于Raspberry Pi的RTMP直播推流器
很早前入了个Raspberry Pi 1代和一个摄像头模组,准备做直播推流设备.
尝试过第一个方案:
raspivid+ffmpeg串流rtmp直播,效果不太好.
ffmpeg对输入流分析太费时,影响直播的时效性.
第二个方案:
后来ffmpeg-3.1好像,更新了OMX实现的H.264编码器,Raspberry Pi通过插入bcm2835-v4l2内核模块,映射出/dev/video0设备,ffmpeg再使用V4L2接口直接进行取摄像头并硬件编码推流.
720分辨率也能行,30帧没有问题,CPU也占用很少,但缺点是分辨率增大后(1080),v4l2取摄像头数据的帧率实在太低,只有6帧左右.
并且不能像raspivid那样方便的设置摄像头参数,比如水平\垂直翻转,角度旋转,亮度,ISO,白平衡这些.
这个方案也被pass.
第三个方案:
参照raspivid,使用OpenMAX IL接口进行摄像头数据捕获->硬件编码->rtmp传输.这个需要进行一点编程开发,由于后来做NodeMediaClient项目,一直耽搁了.
继续阅读“适用于Raspberry Pi的RTMP直播推流器”
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: 适用于Raspberry Pi的RTMP直播推流器
替换Homebrew源为中科大镜像
国内homebrew使用体验很的很差,主要问题是访问github速度太慢,经常卡死在update.
国内homebrew使用体验很的很差,主要问题是访问github速度太慢,经常卡死在update.
替换为中科大镜像,立即起飞.
首先替换Git repo
|
1 2 3 4 5 6 7 8 9 10 11 |
替换brew.git: cd "$(brew --repo)" git remote set-url origin https://mirrors.ustc.edu.cn/brew.git 替换homebrew-core.git: cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core" git remote set-url origin https://mirrors.ustc.edu.cn/homebrew-core.git 替换homebrew-cask.git: cd "$(brew --repo)/Library/Taps/caskroom/homebrew-cask" git remote set-url origin https://mirrors.ustc.edu.cn/homebrew-cask.git |
然后替换Bottles
|
1 2 3 4 5 6 7 |
对于bash用户： echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.ustc.edu.cn/homebrew-bottles' >> ~/.bash_profile source ~/.bash_profile 对于zsh用户 echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.ustc.edu.cn/homebrew-bottles' >> ~/.zshrc source ~/.zshrc |
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: 替换Homebrew源为中科大镜像
macOS 10.12 Sierra上开启原生NTFS写入
Mac上自动挂载的磁盘本身是不允许NTFS写入的。
本文使用osxfuse和ntfs-3g免费原生支持
Mac上自动挂载的磁盘本身是不允许NTFS写入的。
有几款商用软件，像Tuxera NTFS和Paragon NTFS，如果喜欢正版可以支持。
这里介绍一种免费的方式，ntfs-3g 继续阅读“macOS 10.12 Sierra上开启原生NTFS写入”
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: macOS 10.12 Sierra上开启原生NTFS写入
RTMP流媒体服务端应用开发系列 – Nginx-Rtmp-Win32实时转码
首先,为什么需要转码?
目前,Flash作为跨平台,跨浏览器的多媒体插件,在基于浏览器的视频直播发布应用上,仍然是不可替代的.
但它输出RTMP直播流时有个致命问题,只支持Speex或NellyMoser,不支持AAC音频编码.
即使是Flash Media Live Encoder这种应用程序仍然需要购买付费差价才能支持,不知道Adobe是处于什么考虑.
支持AAC有什么好处? 那太多了.
1.转出的HLS流可以直接被iOS/Android播放,可以使用HTML5技术在绝大多数浏览器内进行播放.
2.转出的HTTP-FLV流也可以依靠flv.js在绝大多数浏览器内进行播放,并且实时性非常好.
3.保存的录像文件可以被绝大多数播放器直接播放,speex/nellymoser很可能就无声了.
Nginx-Rtmp-Win32程序怎么实时转码? 继续阅读“RTMP流媒体服务端应用开发系列 – Nginx-Rtmp-Win32实时转码”
原创文章，转载请注明： 转载自贝壳博客
RTMP流媒体服务端应用开发系列 – Nginx-Rtmp-Win32仿星域CDN鉴权配置
Nginx-Rtmp-win32 服务器开启仿星域CDN的鉴权配置,播放防盗链,推流鉴权
之前在RTMP流媒体服务端应用开发系列 – Nginx-Rtmp鉴权设置这篇中介绍了Nginx-Rtmp服务器通过on_play和on_publish事件回调到http服务上,再用ngx_http_secure_link_module进行鉴权.
今天介绍一种原生的方式
注:只在博主编译的Nginx-Rtmp-Win32版本中有此功能
下载https://github.com/illuspas/nginx-rtmp-win32/archive/master.zip版本
首先配置nginx.conf
继续阅读“RTMP流媒体服务端应用开发系列 – Nginx-Rtmp-Win32仿星域CDN鉴权配置”
原创文章，转载请注明： 转载自贝壳博客
在Android端SDK实现了RTMFP协议
做直播这门也有个5年多了,RTMFP协议是梦寐以求的移动客户端实现.在今天,还是成功实现到Android上了.
注意,不是flash,不是AIR哦,而是真正原生c\c++实现.
rtmfp是个激动人心的技术,udp传输\p2p连接\NetGroup,很可能改变直播行业的现状.
欢迎尝鲜:https://github.com/NodeMedia/NodeMediaClient-Android/releases/tag/v2.0.1
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: 在Android端SDK实现了RTMFP协议
SRS-win32 版更新,支持HTTP-FLV
srs-win32编译版 simple rtmp server是Linux环境下运营级流媒体服务器SRS的windows编译版,目的是方便windows平台开发者快速部署流媒体服务器开发测试环境.
同经典的Nginx-Rtmp-Win32项目一样,SRS-win32编译版提供了基本的RTMP\HLS服务.另外,还提供了目前直播app中非常流行的HTTP-FLV格式.
同样,该项目不建议做运营使用,项目是在cygwin环境下编译,默认最大打开文件数256,尽管可以在cygwin环境下修改ulimit数(2016.9.22:最新版2.0.217已默认设置最大打开文件数1024,注意:后来经过验证,即使是改了这地方,程序仍然不能开上百个连接), 但是由于没有Linux环境的epoll,无法高并发.但作为开发测试用已经足够了.
非常建议之前使用Nginx-Rtmp-Win32的开发者使用此项目.
都散了吧,博主精力有限,不会再出新版本了.
如果希望使用Windows平台开发,可以试试博主用Node.js实现的服务端:Node-Media-Server 真正跨平台,高性能谈不上,但上千路没有一点问题.流媒体服务不像HTTP,连接数还没上去,带宽已经跑满了,别太在意并发数.支持RTMP输入,RTMP/HTTP-FLV/WEBSOCKET-FLV输出,支持GOP_CACHE,推流鉴权,播放防盗链.
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: SRS-win32 版更新,支持HTTP-FLV