今天需要给3D打印机装一个监控，正好有个C920和orangepi zero2闲置。
usb插入设备
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使用嵌入式设备直播
查找当前目录下所有flv文件，复制音视频，转换为mp4格式并修改后缀名
for f in *.flv; do ffmpeg -i $f -c copy ${f:0:0-4}.mp4; done查找当前目录下所有mp4文件，使用aac, x265重新编码，保存为mkv格式并修改后缀名
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中的Beon，现在叫asimd。
在js运行环境中，目前还没有完美的线程方案来利用多核解码，那么我们可以优化至少让单核进行并行运算。这是chrome91和firefox89正式带来的WebAssembly SIMD技术。
NodePlayer.js 更新v0.10.1版，利用这项技术，在高分辨率解码环境下，带来比SISD性能提升1倍以上！尤其是在高分辨率，HEVC解码下。
测试对比：
首先准备一个hevc编码，2M码率，1080分辨率，30帧的视频
ffprobe http://192.168.0.3:8000/live/enc1.flv
ffprobe version 4.3.2 Copyright (c) 2007-2021 the FFmpeg developers
built with Apple clang version 13.0.0 (clang-1300.0.29.30)
configuration: --enable-small --disable-doc --enable-libsrt --enable-libfreetype --enable-libspeex --enable-libx264 --enable-libx265 --enable-openssl --enable-gpl --enable-nonfree --enable-version3 --enable-libopenh264 --cc='ccache cc'
libavutil 56. 51.100 / 56. 51.100
libavcodec 58. 91.100 / 58. 91.100
libavformat 58. 45.100 / 58. 45.100
libavdevice 58. 10.100 / 58. 10.100
libavfilter 7. 85.100 / 7. 85.100
libswscale 5. 7.100 / 5. 7.100
libswresample 3. 7.100 / 3. 7.100
libpostproc 55. 7.100 / 55. 7.100
Input #0, flv, from 'http://192.168.0.3:8000/live/enc1.flv':
Metadata:
encoder : Lavf57.71.100
server : NMS v3.14.2
Duration: 00:00:00.00, start: 91.998000, bitrate: N/A
Stream #0:0: Audio: aac, 48000 Hz, stereo, fltp, 128 kb/s
Stream #0:1: Video: hevc, yuv420p(tv, bt709), 1920x1080, 2000 kb/s, 30.30 fps, 30 tbr, 1k tbn, 30 tbc
可以看出，WASM版解码cpu占用90.6% ，而SIMD版解码cpu占用42.3%，达到1倍以上的性能提升！
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毫秒！
原创文章，转载请注明： 转载自贝壳博客
前面有介绍如何在白鹭引擎中使用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，关闭硬件编码，模拟无硬件加速的环境。
继续阅读原创文章，转载请注明： 转载自贝壳博客
最近正在开发的NMSv3版本，新增了一个激动人心的特性：KMP协议。
这是一个基于可靠UDP传输的流媒体协议，支持推流与播放。
K是什么意思呢，当然是快啦 😛 ，不保留的说，是kcp。
KMP全称 Kuai-Media-Protocol， 又土又俗，我喜欢。kcp相信各位善于【那啥】的老哥都懂，不清楚的请自行google。
我接触RTMP协议，初算下，大概8年多了。 一个我自认为互联网历史里最具色彩的flash技术中的一个网络传输协议。眼见flash起高楼，宴宾客，楼塌了，chrome每天都在善意的提醒判决死缓2020 年12 月执行。当然这丝毫不改变我觉得Adobe是伟大的公司。 就这么个遗产，成为了当今世界视频直播领域的标准，带动了多少产业–游戏主播与平台、网红直播带货等等等等，创造的价值那真是数不清， http-flv也是它家的技术。
RTMP是基于TCP协议设计的，设计之初估计也没预料到3G, 4G环境, 1080P高码率。可以预见到5G时，直播4k会是很平常的事。网络基础决定上层应用。 网络状况好的时候，体验那是相当好，但稍微开始掉包或者信道拥堵，弊端出现，TCP重传机制这时候会卡成狗。不是说谁的不好，而是交互型视频直播非常在意低延迟，像http协议，也是TCP，但遇到这种情况你不会太在意，因为就是多等一下，结果都一样。但视频就不一样了，一卡一动，音频更难受。HLS协议设计之初就说，咱多缓冲些，大缓存抵消抖动。但国内不喜欢这个，就爱低延迟的。经常有老板说，咱能整进毫秒级延迟不。
Adobe也设计了基于UDP传输的RTMFP协议，还能P2P分流，那是相当牛逼，可惜设计的太复杂了，至今我了解的只有mona一家实现了客、服两端，我也不打算看这个，太南了。
如果网络从来不丢包，那么你直接用 TCP就行了，甚至直接裸UDP都没关系，但是网络因为丢包造成卡顿，特别是高峰时期丢包会上到10%的情况，移动设备上这个情况更糟糕。
— skywind3000/kcp
kcp协议快就快在重传机制上，具体细节咱就不在这儿讨论了。实际上google也提出了BBR算法来加速TCP重传，效果也非常不错，服务器一经开启提升特别明显，而且对现有应用架构没有任何改动，但是只能在linux内核4.9以上开启。
我在kcp基础上，增加了视频封装等应用层协议，实际效果非常理想。
我开了一台洛杉矶机房的VPS，在服务器上部署NMS v3.2.5, 使用ffmpeg循环推流一个1.2M码率的720p视频。大部分时候，国内rtmp协议访问很卡顿，大概有200ms的延迟，30%以上的丢包率。而使用kmp协议访问的话，基本上是流畅的。
windows测试工具： http://www.nodemedia.cn/products/node-media-client/windows/
kmp测试地址：kmp://shoe.nodemedia.cn/demo/xxm
rtmp测试地址：rtmp://shoe.nodemedia.cn/demo/xxm
当然也可以在本地部署测试服务器，只需要使用linux的tc工具模拟丢包就行。
http://senlinzhan.github.io/2019/04/15/linux-loss-delay/
接下来我会将这个协议加入到android，iOS的SDK中，为移动应用提速。
实际上我也实现了推流的规范，使用KMP协议推流相比RTMP有什么好处呢？显而易见，当你的流媒体服务器在国外，而你还有一部分国内用户需要推流，需求反过来也一样。那直播体验效果绝对飞跃。要知道，播流卡一个，推流卡全部。
KMP协议还可以应用在服务器之间relay，试想如果在全球部署流媒体服务器，那么流分发时使用KMP协议，即使是跨越大洲大洋，依然能保持低延迟！
另外，文中提到的KMP协议只有我开发的NMSv3支持。
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: 基于可靠UDP传输的KMP视频直播协议
还记得我刚入行时，那时候3G还没普及，做视频只能做172×144，清晰点的320×240。取监控画面大多还是352×288，或者很高清的D1了。
在视频领域现如今，短短几年时间，网络带宽飞速提升，图像传感器的像素越来越大，人们对画质的追求也越来越高。1080只是起步，2K, 4K的应用也不在少数。
传统的H264算法在这时候捉襟见肘，更高级的编码规范应运而生。HEVC也就是H265，VP9，AV1，还有我国的视频标准AVS2就是它的继任者。谁能在这场较量中胜出呢。
高效率视频编码（High Efficiency Video Coding，简称HEVC），又称为H.265和MPEG-H第2部分，是一种视频压缩标准，被视为是ITU-T H.264/MPEG-4 AVC标准的继任者。
我接触到的业务很多和视频监控领域相关，近一两年来，越来越多的监控厂家新出厂的设备，默认采用H265视频编码了。当我们要部署这类视频应用时，客户端解码是个大问题。pc应用可以采用厂商提供的SDK，通用一点的办法是使用ffmpeg的HEVC解码器。而更多的企业应用更愿意部署在web平台，在浏览器中播放。
我们通过这个链接(1)可以查到，只有ie11，edge12-18具有硬件解码能力的才能支持。Apple系macOS在10.13 High Sierra，iOS在11以后可以原生支持。所有chrome系不支持。windows不提供软解解码h265的能力，只有显卡硬件支持才能支持，而且edge马上要更换到chrome平台了。毕竟H265授权费是很高的，像微软这种用户量级，那肯定是天价，干脆交给显卡厂商来处理。苹果本身是这个标准组织的成员，有大量这方面的专利，因此它很乐意推广这个标准。在WWDC17上，苹果就宣布HLS格式支持HEVC编码，(2) 需要使用fMP4进行切片。NMSv3.2开始，支持输出HEVC编码的HLS流。
那么要实现通用的跨平台，跨浏览器支持的解码器方案，现如今只有1个方法，WASM，NodePlayer.js便支持这种方式。我也曾在一款海康NVR上发现它的web控制器也采用了这种方式，数据通过websocket传输，但不是一种通用的标准。当然这种方式解码性能不足，面对高清画面解码时要求本地机器有很强的单核处理性能。海康便要求一次只能播放一个高清主码流。而NodePlayer.js v0.6版，采用webworker方式，将多路解码分散到多个进程中，提升了多路视频打开时的处理能力。并且传输协议也是目前最常见的http-flv，websocket-flv，支持包括nms，阿里云直播服务。也兼容阿里云H265 over http-flv。
后记：其实我们还是有很多其它选择，google系开放的VP9,和VP9的继任者AV1，至少在Apple系以外可以得到广泛的支持。国家的视频标准AVS2，目前很少有接触到软硬件的应用。后期我会在AV1和AVS2上做一些研究，风云变幻谁又能说的定呢。
2021-7-26日更新：NodeMediaServer 更新到v3.9.6, 支持http-fmp4直播流，HEVC获得原生媒体协议支持。ffplay，vlc等都无需打flv_id=12的补丁，即可播放。Chrome浏览器支持<video>标签直接打开，且windows系统下360浏览器可直接解码HEVC，无需安装任何插件。
原创文章，转载请注明： 转载自贝壳博客
本文链接地址: 浏览器播放H265/HEVC视频的可行性分析