前期曾发布过一款windows平台RTMP推送摄像头画面的浏览器插件，近期对这款产品进行了升级，现已支持捕获桌面画面进行推流。
桌面推流当然首选OBS，专业性毋庸置疑。本人开发的这款产品定位为简单业务需求，只需引导客户安装5M左右大小的插件程序，无需任何配置，即可在web网页中进行摄像头或桌面画面的捕获推流。
在本次更新中，加入了H.265编码器的支持，视频码率更低。同时，在SSE指令集加速的软编码基础上，增加了AMD/NVIDIA/INTEL独显核显硬件加速编码，CPU消耗更低。
本插件同时也加入了直播播放器的支持，可以播放rtmp，rtsp，http协议的直播流，并支持硬件加速解码，首屏秒开与延迟消除技术。继续阅读
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: Windows平台浏览器内捕获桌面画面并RTMP推流
这是困扰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直播
最近在研究用Emscripten开发JavaScript的直播播放器，使用ffmpeg内置的h264解码速度还是可以接受的，本想使用openh264的解码进行比较，但发现非常慢，无法达到640×480@30帧的解码速度。
本来以前也有过用openh264的项目，直接使用libopenh264进行解码速度还是很快的。但编译进ffmpeg里使用就特别慢，于是-g重新编译NodePlayer.js并开始Chrome Performance录制。
继续阅读
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: ffmpeg.js使用libopenh264解码性能低的原因
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的浏览器环境内实现 “真·实时视频播放”
Hi35xx 的音频输入和音频输出模块支持对音频数据实施重采样。如果启用 AI 重采样功 能，则在 HI_MPI_AI_GetFrame 获取数据返回前，内部将会先执行重采样处理，再返 回处理后的数据。如果启用了 AO 重采样功能，则音频数据在发送给 AO 之前，内部 先执行重采样处理，处理完成后再发送给 AO 通道进行播放。
音频重采样支持任意两种不同采样率之间的重采样。重采样支持的输入输出采样率 为:8kHz，11.025kHz，12kHz，16kHz，22.05kHz，24kHz，32kHz，44.1kHz， 48kHz。
重采样仅支持处理单声道，且不支持同时进行回声抵消处理。
当你使用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 媒体处理平台开发参考阅读笔记 二
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: 海思 HiMPP-IPC 媒体处理平台开发参考阅读笔记 一
第一次尝试用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
1.安装了speex但找不到
ERROR: speex not found using pkg-config
pacman -S pkg-config
2.configure 配置完以后提示找不到cmp命令
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
pacman -S diffutils
……后续继续补充
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: 使用MSYS2编译Windows平台FFmpeg问题集合
很早前入了个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直播推流器