by ·0评论

NVIDIA TensorRT™是一个高性能深度学习推理平台。它包括深度学习推理优化器和运行时，可为深度学习推理应用程序提供低延迟和高吞吐量。在推理期间，基于TensorRT的应用程序比仅CPU平台的执行速度快40倍。使用TensorRT，您可以优化在所有主要框架中培训的神经网络模型，以高精度校准低精度，最后部署到超大规模数据中心，嵌入式或汽车产品平台。

         TensorRT构建于NVIDIA的并行编程模型CUDA之上，使您能够利用CUDA-X AI中的库，开发工具和技术，为人工智能，自动机器，高性能计算和图形优化所有深度学习框架的推理。

         TensorRT为深度学习推理应用的生产部署提供INT8和FP16优化，例如视频流，语音识别，推荐和自然语言处理。降低精度推断可显着减少应用程序延迟，这是许多实时服务，自动和嵌入式应用程序的要求。

image.png

         您可以将训练有素的模型从每个深度学习框架导入TensorRT。应用优化后，TensorRT选择特定于平台的内核，以最大限度地提高数据中心，Jetson嵌入式平台和NVIDIA DRIVE自动驾驶平台中Tesla GPU的性能。

         为了在数据中心生产中使用AI模型，TensorRT推理服务器是一种容器化微服务，可最大化GPU利用率，并在节点上同时运行来自不同框架的多个模型。它利用Docker和Kubernetes无缝集成到DevOps架构中。

         使用TensorRT，开发人员可以专注于创建新颖的AI驱动的应用程序，而不是用于推理部署的性能调整。

继续阅读

by ·0评论

最近得空，搞了一块Jetson Nano玩玩。

NVIDIA  在2019年NVIDIA GPU技术大会（GTC）上发布了Jetson Nano开发套件，这是一款售价99美元的计算机，现在可供嵌入式设计人员，研究人员和DIY制造商使用，在紧凑，易用的平台上提供现代AI的强大功能。完整的软件可编程性。Jetson Nano采用四核64位ARM CPU和128核集成NVIDIA GPU，可提供472 GFLOPS的计算性能。它还包括4GB LPDDR4存储器，采用高效，低功耗封装，具有5W / 10W功率模式和5V DC输入，如图1所示。

新发布的JetPack 4.2 SDK  为基于Ubuntu 18.04的Jetson Nano提供了完整的桌面Linux环境，具有加速图形，支持NVIDIA CUDA Toolkit 10.0，以及cuDNN 7.3和TensorRT等库。该SDK还包括本机安装流行的功能开源机器学习（ML）框架，如TensorFlow，PyTorch，Caffe，Keras和MXNet，以及计算机视觉和机器人开发的框架，如OpenCV和ROS。

完全兼容这些框架和NVIDIA领先的AI平台，可以比以往更轻松地将基于AI的推理工作负载部署到Jetson。Jetson Nano为各种复杂的深度神经网络（DNN）模型提供实时计算机视觉和推理。这些功能支持多传感器自主机器人，具有智能边缘分析的物联网设备和先进的AI系统。甚至转移学习也可以使用ML框架在Jetson Nano上本地重新训练网络。

话不多说直接开干。

继续阅读

by ·0评论

clang在Windows下可以很方便的引用msys2的开发环境。

vscode在linux，mac下安装cmake tools插件也差不多能达到相同功能。

但该插件在windows下，想要引用msys2还是遇到问题了。

ctrl+p，>CMake:Edit User-Local CMake Kits 需要如下设置：

添加environmentVariables是关键

by ·0评论

简述

NodePlayer.js设计之初只是为了播放http-flv协议，但经常有客户想要知道能否播放RTMP协议，甚至RTSP协议，以往我们的回答都是不能。web浏览器没有开放TCP/UDP协议，当然无法实现RTMP、RTSP播放了。

但从 NodePlayer.js-v0.7版本开始，我们已经实现RTMP协议的播放了！
当然，不是TCP协议的RTMP, 没有这个基础条件。我们实现的方式，是通过WebSocket协议来和一个 websocket 2 tcp 服务交换协议，最终和RTMP服务器建立连接。

本播放器无需flash插件，和video.js等播放RTMP的方式完全不同。

目的

如果您正在构建新的直播项目，其实无需使用本技术。如今的流媒体服务端或者云服务，基本上都支持HTTP-FLV甚至WebSocket-FLV。
本功能是为以往使用Flash-Media-Server, Adobe-Media-Server, Nginx-RTMP, Red5，Wowza等服务端构建项目的用户，在不改变现有架构的条件下，无痛迁移到HTML5播放器。

部署方法

实际上无需过多要求，只需要一个 websocket to tcp的桥接服务。
这里，我们以一个非常轻量级，且开放源代码的ws-tcp-relay项目为例。
项目地址：https://github.com/isobit/ws-tcp-relay

进入https://github.com/isobit/ws-tcp-relay/releases ，根据服务端系统选择并下载应用程序

下载后，linux系统下添加可执行权限，然后执行

参数说明：
-b 使用binary格式传输
-p 绑定本机8080端口监听websocket连接
192.168.0.3:1935 需要桥接的远端或者本地 rtmp服务，本机可以填 127.0.0.1:1935

播放方法

使用NodePlayer.js-v0.7版播放器，播放地址

即可

如果要去掉端口号， ws-tcp-relay改为监听80端口，但可能会和webserver冲突
这里不清楚nginx反向代理是否有能力转websocket to tcp，如果能的话那就更方便。

播放器演示地址

http://www.nodemedia.cn/uploads/nodeplayer_rtmp.html

使用前请先运行ws-tcp-relay服务

RTSP流？

理论上，也是可以的，敬请期待。

by ·0评论

这种情况不管是本地运行WordPress还是阿里云ecs上，安装更新、插件、主题，都会出现。估计是woredpress的cdn对国内ip做了限流。

我解决的办法是给添加一个http proxy来解决，注意一定要是http_proxy，socks5请加一层代理转换，比如privoxy。

非常简单，打开wp-config.php，在合适的位置添加：

by ·2条评论

首先我们知道，Rtmp是一种客户端到服务端的技术，Peer to Server。WebRTC是一种客户端到客户端的技术，Peer to Peer。

Rtmp通过一个TCP连接，向服务端发送或接收连接信息，媒体数据。

WebRTC先使用ICE技术连接STUN/TURN，得到自己的连接信息。再绑定音视频设备获取媒体信息，拼装为SDP信令。两个客户端通过任意方式交换信令，建立客户端直接的连接，再使用RTP发送和接收媒体数据。

如果一个服务端实现了WebRTC客户端的能力，那么它也可以被认为是一个Peer，与用户浏览器的WebRTC客户端创建连接，获得客户端推送过来的媒体数据，就完成了Peer to Server的转换。

继续阅读

by ·0评论

xcode 11.3.1 已安装，执行

出现错误

执行下面的命令，安装后, 问题解决

by ·一条评论

最近在研究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，关闭硬件编码，模拟无硬件加速的环境。

继续阅读

by ·3条评论

华为云服务“通用计算增强型KC1”已正式商用，今天准备测试一下NMSv3的兼容运行情况。如果还没有华为云账户的话，先注册一个。

搭载自研华为鲲鹏920处理器及25GE智能高速网卡，提供强劲鲲鹏算力和高性能网络，更好满足政府、互联网等各类企业对云上业务高性价比、安全可靠等诉求。

鲲鹏920是目前业界最高性能ARM-based处理器。该处理器采用7nm制造工艺，基于ARM架构授权，由华为公司自主设计完成。鲲鹏920主频可达2.6GHz，单芯片可支持64核。该芯片集成8通道DDR4，内存带宽超出业界主流46%。芯片集成100G RoCE以太网卡功能，大幅提高系统集成度。鲲鹏920支持PCIe4.0及CCIX接口，可提供640Gbps总带宽，单槽位接口速率为业界主流速率的两倍，有效提升存储及各类加速器的性能。典型主频下，SPECint Benchmark评分超过930，超出业界标杆25%。同时，能效比优于业界标杆30%。鲲鹏920以更低功耗为数据中心提供更强性能。

那我先来开一个最便宜的配置：

kc1.small.11vCPUs | 1GBHuawei Kunpeng 920 2.6GHz0.5/2 Gbit/s200,000¥59.25/月

好了，基本情况就是这样，来下载最新版NMSv3，可以看到北京四机房访问github的速度还不错，6M的程序4秒就完成了。

NMSv3 最新发布地址已更改，使用新的地址和版本。

没有任何问题，运行成功。GO语言开发跨平台软件的优势确实强大，不过由于NMSv3中使用了CGO技术，否则可以生成更多的目标平台。我将会在下阶段移植下龙芯处理器mips64el架构。

打开nms的web后台，一切正常。

推流并在本机播放1000个rtmp测试。

这是一个500kbps变码率的视频，1000个并发内部带宽达到600M左右，cpu占用20%~40%。由于1000个并发测试程序是在本机运行，所以也会占用一定的cpu。

由此可见，华为鲲鹏云KC1实例，即使是最低配置1核1G也是完全能够满足性能需求，因为流媒体应用最大的瓶颈是网络带宽。如果您需要使用到自主服务的话，华为鲲鹏云也是不错的选择。

by ·0评论

最近正在开发的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支持。