为CasaOS Docker环境下的jellyfin安装Tesla p4显卡加速

我的NAS使用E5处理器,由于没有编解码硬件加速,在用jellyfin播放h265 10bit HDR时会进行实时转码,cpu占用1800%,功耗150W。

Tesla P4这张卡现在价格来到300块,8G的显存,接近1060的3D性能,可以达到多路4K@60的编解码性能,非常适合。

我的NAS系统安装Debian12 CasaOS,这里记录下配置过程。

一、首先安装必要的包

二、初次运行驱动,会提示加载了开源驱动,问是否自动进行关闭,选yes,然后重启系统

继续阅读“为CasaOS Docker环境下的jellyfin安装Tesla p4显卡加速”

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

本文链接地址: 为CasaOS Docker环境下的jellyfin安装Tesla p4显卡加速

罗技C920使用嵌入式设备直播

今天需要给3D打印机装一个监控,正好有个C920和orangepi zero2闲置。

usb插入设备

可以看到已识别到设备,由于这款C920摄像头内集成264编码,因此通过v4l是可以直接从摄像头取264视频的,那么直接开始直播。

继续阅读“罗技C920使用嵌入式设备直播”

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

本文链接地址: 罗技C920使用嵌入式设备直播

FFMpeg linux下批量处理命令行

查找当前目录下所有flv文件,复制音视频,转换为mp4格式并修改后缀名

查找当前目录下所有mp4文件,使用aac, x265重新编码,保存为mkv格式并修改后缀名

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

本文链接地址: FFMpeg linux下批量处理命令行

NodePlayer.js正式支持SIMD解码加速

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解码加速

TSDebugger一款直播流调试工具

一款用于调试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一款直播流调试工具

NodePlayer.js挑战播放1080p live-http-flv 100毫秒级延迟

要挑战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挑战播放1080p live-http-flv 100毫秒级延迟

在Laya引擎中使用NodePlayer.js开发直播视频游戏

简介

前面有介绍如何在白鹭引擎中使用NodePlayer.js,今天做了Laya引擎的集成尝试,方法如下。

环境

NodePlayer.js wasm版 v0.5.42
LayaAir 2.8.0beta2
LayaAir IDE 2.8.0beta2

创建项目

新建一个2D示例项目,编程语言使用TypeScript

拷贝并引用播放器

1.将wasm版的试用开发包或者授权开发包解压,准备

继续阅读“在Laya引擎中使用NodePlayer.js开发直播视频游戏”

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

本文链接地址: 在Laya引擎中使用NodePlayer.js开发直播视频游戏

在白鹭引擎中使用NodePlayer.js开发直播视频游戏

简介

实时视频+游戏操作是非常不错的娱乐体验方式,结合物联网设备可以开发诸如:远程抓娃娃、远程打气球、打野兔、射箭等项目。
NodePlayer.js-wasm版可以非常方便的集成到最新的白鹭引擎(v5.3以上)中使用,以下是我们总结的一个集成方法。

一、准备工作

1.NodePlayer.js wasm版

试用开发包请下载:https://cdn.nodemedia.cn/NodePlayer/0.5.39-wasm/NodePlayer_v0.5.39-wasm_trial.zip
授权用户请准备好wasm版

2.白鹭引擎 v5.3.8

3.Egret Compiler

4.Egret Wing 3

二、创建并打开工程

继续阅读“在白鹭引擎中使用NodePlayer.js开发直播视频游戏”

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

本文链接地址: 在白鹭引擎中使用NodePlayer.js开发直播视频游戏

WebRTC 研究系列 一、Chrome开启硬件编码后,rtp包H264 Payload的差异

最近在研究NMSv3 接入WebRTC协议,以实现浏览器跨平台无插件高清推流,服务端转http-flv,rtmp等。首选视频编码当然是H264了,这样服务端只需做音频实时转码OPUS->AAC即可。

在解析RTP包内H264负载时遇到各种坑,这里记录一下。

环境:

  • OS:MacOS 10.14.6
  • Chrome : 80.0.3987.106

一、查看默认编码器参数,浏览器访问 chrome://gpu/

Video Acceleration Information

Decode h264 baseline16×16 to 4096×2160 pixels
Decode h264 extended16×16 to 4096×2160 pixels
Decode h264 main16×16 to 4096×2160 pixels
Decode h264 high16×16 to 4096×2160 pixels
Encode h264 baseline0x0 to 4096×2160 pixels, and/or 30.000 fps
Encode h264 main0x0 to 4096×2160 pixels, and/or 30.000 fps
Encode h264 high0x0 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的差异”

基于可靠UDP传输的KMP视频直播协议

最近正在开发的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视频直播协议