致力于流媒体技术研究
我的NAS使用E5处理器，由于没有编解码硬件加速，在用jellyfin播放h265 10bit HDR时会进行实时转码，cpu占用1800%，功耗150W。
Tesla P4这张卡现在价格来到300块，8G的显存，接近1060的3D性能，可以达到多路4K@60的编解码性能，非常适合。
我的NAS系统安装Debian12 CasaOS，这里记录下配置过程。
一、首先安装必要的包
|
1 |
apt install linux-headers-amd64 gcc make libvulkan1 pkg-config |
二、初次运行驱动，会提示加载了开源驱动，问是否自动进行关闭，选yes，然后重启系统
|
1 |
./NVIDIA-Linux-x86_64-535.104.05-grid.run |
原创文章，转载请注明： 转载自贝壳博客
今天需要给3D打印机装一个监控，正好有个C920和orangepi zero2闲置。
usb插入设备
|
1 2 3 4 5 6 7 8 9 10 |
root@orangepizero2:~# v4l2-ctl --list-devices cedrus (platform:cedrus): /dev/video0 /dev/media0 HD Pro Webcam C920 (usb-5200000.usb-1): /dev/video1 /dev/video2 /dev/media1 |
可以看到已识别到设备，由于这款C920摄像头内集成264编码，因此通过v4l是可以直接从摄像头取264视频的，那么直接开始直播。
继续阅读“罗技C920使用嵌入式设备直播”原创文章，转载请注明： 转载自贝壳博客
本文链接地址: 罗技C920使用嵌入式设备直播
查找当前目录下所有flv文件，复制音视频，转换为mp4格式并修改后缀名
|
1 |
for f in *.flv; do ffmpeg -i $f -c copy ${f:0:0-4}.mp4; done |
查找当前目录下所有mp4文件，使用aac, x265重新编码，保存为mkv格式并修改后缀名
|
1 |
for f in *.mp4; do ffmpeg -i $f -c:a aac -c:v libx265 ${f:0:0-4}.mkv; done |
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: FFMpeg linux下批量处理命令行
SIMD全称Single Instruction Multiple Data，单指令多数据流，能够复制多个操作数，并把它们打包在大型寄存器的一组指令集。
以加法指令为例，单指令单数据（SISD）的CPU对加法指令译码后，执行部件先访问内存，取得第一个操作数；之后再一次访问内存，取得第二个操作数；随后才能进行求和运算。而在SIMD型的CPU中，指令译码后几个执行部件同时访问内存，一次性获得所有操作数进行运算。这个特点使SIMD特别适合于多媒体应用等数据密集型运算。
在微处理器中，单指令流多数据流技术则是一个控制器控制多个平行的处理微元，如X86中的SSE,AVX，Arm中的Neon，现在叫asimd。
在js运行环境中，目前还没有完美的线程方案来利用多核解码，那么我们可以优化至少让单核进行并行运算。这是chrome91和firefox89正式带来的WebAssembly SIMD技术。
NodePlayer.js 更新v0.10.1版，利用这项技术，在高分辨率解码环境下，带来比SISD性能提升1倍以上！尤其是在高分辨率，HEVC解码下。
测试对比：
可以看到，SIMD版解码在大多数场景下，CPU占用率只有WASM的1/3 。
wasm 版在线demo：http://demo.nodemedia.cn/uploads/nodeplayer_wasm.html
simd 版在线demo：http://demo.nodemedia.cn/uploads/simd/index.html
NodePlayer.js 文档：https://www.nodemedia.cn/doc/web/#/1?page_id=1
原文地址：NodePlayer.js正式支持SIMD解码加速 | 诺德美地流媒体系统 (nodemedia.cn)
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: NodePlayer.js正式支持SIMD解码加速
一款用于调试RTMP、KMP、HTTP-FLV流时间戳的小工具。
通过这个工具，可以直观的打印出每一帧音视频的信息，包括时间戳，包大小。
一个流畅的直播视频应该符合以下三个状态
一、每一帧数据匀速打印，无停顿。如果停止打印说明无数据返回，有两种情况：第一种是推流端网络阻塞，第二种是播放端网络阻塞。这个比较好判断，使用两台机器测试，如果停顿在同一个时间点，则是推流端阻塞；分别在不同的时间点停顿，则是播流端阻塞。还需要对服务端的上下行带宽进行评估是否已达上限。
二、音视频帧交替打印
以44100采样的aac举例，aac编码一个包需要1024个采样。这时，一帧的时长就是 1000/44100*1024 约等于23.219954648526077毫秒。
如果视频是30fps，则一帧的时长是1000/30 约等于33.3333毫秒。
这时候音视频一般会是AVAVAAV的排列。
如果出现连续上10个以上同类型包，则要考虑是否是编码器音视频编码不同步。
三、时间戳增长与时钟增长频率一致
RTMP，KMP、HTTP-FLV的时间基是1/1000秒，因此通过观察单位时间内时间戳的增长数应该与时钟一致。如果不一致，常见于从其它协议转RTMP时，时间单位换算错误。如RTSP: H264/90000 PCMA/8000
下载地址：https://github.com/illuspas/tsdebugger
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: TSDebugger一款直播流调试工具
要挑战100毫秒级的p2s2p型直播，我们首先要了解延迟到底是怎么产生的？
1.推流端p采集原始画面，交给编码器编码，根据编码复杂度，编码器缓存，在这里就产生了延迟。（可控参数较多，影响较大）
2.推流端p编码后推送到s服务端，网络传输产生延迟。（以现在的网络环境，影响小）
3.服务端s接收地视频后进行协议转换，不同的服务实现可能会在这里造成一点延迟。（以现在的服务端性能，影响小）
4.播放端p播放，网络传输产生延迟。（以现在的网络环境，影响小）
5.播放端p解码渲染、缓冲队列产生延迟。（音视频同步、数据缓冲、延迟消除算法复杂，影响很大）
由此可以看出，要实现低延迟，重点优化推播两端是效果最明显的。
测试环境：
OBS设置x264软编码，CBR，2500kbps, veryfast，zerolatency，baseline，1s gop，0 buffer，视频尺寸1920×1080@30
推流到本机NMS-v3.7.3 （忽略网络对延迟的影响，测试极限条件）
NodePlayer.js-v0.5.56, bufferTime设置为0
实测，最低延迟79毫秒！
原创文章，转载请注明： 转载自贝壳博客
最近实现了NMSv3接收GB28181设备注册，下发指令主动通知摄像头以RTP推流到NMS，转为RTMP, KMP, FLV播放。
NMSv3不是完整的GB28181实现，我将SIP信令与RTP流媒体服务器合二为一，仅作为实时视频取流的用途。
当我准备实现设备注册，密码验证时，找到一篇博文：https://blog.csdn.net/hiccupzhu/article/details/39696981
其中讲到的算法是：
HA1=MD5(username:realm:passwd) #username和realm在字段“Authorization”中可以找到，passwd这个是由客户端和服务器协商得到的，一般情况下UAC端存一个UAS也知道的密码就行了
HA2=MD5(Method:Uri) #Method一般有INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER；Uri可以在字段“Authorization”找到
response = MD5(HA1:nonce:HA2)
对比REGISTER中的response与计算的response，相同则验证通过。
但我却验证错误，仔细阅读了exosip这部分的代码后，终于找出差异：https://github.com/aurelihein/exosip/blob/master/src/jauth.c#L144
当设备第一次发送REGISTER，NMS回复401, 并附带
|
1 |
WWW-Authenticate: Digest realm="3402000000", nonce="a321cfdd39ff6233" |
还有一种回复是
|
1 |
WWW-Authenticate: Digest realm="3402000000", qop="auth"， nonce="a321cfdd39ff6233" |
原来这个qop的设置与否，决定了验证算法的差异。
当不设置qop时，确实是使用上面的那种算法进行验证。而设置为”auth”后，则使用下面的这个算法：
HA1=MD5(username:realm:passwd) #username和realm在字段“Authorization”中可以找到，passwd这个是由客户端和服务器协商得到的，一般情况下UAC端存一个UAS也知道的密码就行了
HA2=MD5(Method:Uri) #Method一般有INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER；Uri可以在字段“Authorization”找到
response = MD5(HA1:nonce:nc:cnonce:qop:HA2)
可以看出，HA1、HA2是相同的，区别在于resopnse有差别。开发时需要注意这点，如果想使用简单的验证算法，回复401时，不要传qop=”auth”参数。
另外还有一种qop=”auth-int”的算法，这里由于决定权在服务端，所以不做详细研究。如果做向上级级联，则要根据上级401的参数来响应。
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: GB28181 设备注册密码验证算法
前面有介绍如何在白鹭引擎中使用NodePlayer.js，今天做了Laya引擎的集成尝试，方法如下。
NodePlayer.js wasm版 v0.5.42
LayaAir 2.8.0beta2
LayaAir IDE 2.8.0beta2
新建一个2D示例项目，编程语言使用TypeScript
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: 在Laya引擎中使用NodePlayer.js开发直播视频游戏
实时视频+游戏操作是非常不错的娱乐体验方式，结合物联网设备可以开发诸如：远程抓娃娃、远程打气球、打野兔、射箭等项目。
NodePlayer.js-wasm版可以非常方便的集成到最新的白鹭引擎(v5.3以上)中使用，以下是我们总结的一个集成方法。
试用开发包请下载：https://cdn.nodemedia.cn/NodePlayer/0.5.39-wasm/NodePlayer_v0.5.39-wasm_trial.zip
授权用户请准备好wasm版
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: 在白鹭引擎中使用NodePlayer.js开发直播视频游戏
最近在研究NMSv3 接入WebRTC协议，以实现浏览器跨平台无插件高清推流，服务端转http-flv，rtmp等。首选视频编码当然是H264了，这样服务端只需做音频实时转码OPUS->AAC即可。
在解析RTP包内H264负载时遇到各种坑，这里记录一下。
环境：
一、查看默认编码器参数，浏览器访问 chrome://gpu/
| Decode h264 baseline | 16×16 to 4096×2160 pixels |
| Decode h264 extended | 16×16 to 4096×2160 pixels |
| Decode h264 main | 16×16 to 4096×2160 pixels |
| Decode h264 high | 16×16 to 4096×2160 pixels |
| Encode h264 baseline | 0x0 to 4096×2160 pixels, and/or 30.000 fps |
| Encode h264 main | 0x0 to 4096×2160 pixels, and/or 30.000 fps |
| Encode h264 high | 0x0 to 4096×2160 pixels, and/or 30.000 fps |
此刻，RTP包的负载，I包和P包使用FU-A，SPS、PPS采用STAP-A打包。
二、通过访问chrome://flags/ ，将Hardware-accelerated video encode 选项设置为Disable，关闭硬件编码，模拟无硬件加速的环境。
继续阅读“WebRTC 研究系列 一、Chrome开启硬件编码后，rtp包H264 Payload的差异”原创文章，转载请注明： 转载自贝壳博客