superxxd的专栏

矢量地图是通过对点线面坐标信息集合的管理和渲染实现优于栅格画面质量的一种gis展示技术，涉及不同坐标系变换，视窗比例尺换算等。Gis引擎开发是一个综合性要求比较高的任务，可以从简单开始，尽量自己实现比较底层的功能，这样自己在把控整个项目时就不会力有未逮，开源框架虽好但不能贪杯，一定要做自己能把控的事，不要盲目引入太多框架以至后期失控导致项目进退两难。mapbox以及qgis spatialite geos等开源软件仍然是开发引擎的良师益友有些组件可以直接拿来用，可以大大减少开发的难度并提高效率。

流媒体除了常用实时流外还有大部分是以文件的形式存在，做融合预览必须要考虑多种兼容性能力，借用现有的ffmpeg生态可以迅速实现多种格式的支持，现在我们将按需拉流预览功能进行了拓展，正式支持了ffmpeg的功能，可快捷方便的实现除实时流外的，比如mp4文件预览，满足宣贯广告等需求。

在实战开发了大量从服务端到设备端再到浏览器端的应用后蒙生了一个想法，就是将这么多应用的共性问题提炼出来，用物联网的思维统一管理调度并授权管理，用户可以分级分权限发布资源提供能力和数据流，同时通过订阅来实现利用这些资源，我们只是对数据流和控制流进行按需共享，这样一来，就大大减少了系统的逻辑相关性，开发者可以将注意力放到业务按需实现调度逻辑，需要什么定阅什么，没有功能就实现一下独立的应用去发布这个功能让其他订阅者使用。后一步会增加语音电话，物联网采集控制，AI分析赋能，以及利用这些能力订阅，实现多种业务逻辑。

我知道这个挑战很大，也有很多超过我的能力，但我相信在互联网深入人心，协作共享成为主流趋势的现今这个平台一定有价值，一定会有不同的人愿意来尝试并迭代并完善他，在这里我想致敬#casdoor #hotgo#goadmin是这些优秀的设计给了我启发和初步的能力。1.资源管理,包括流和设备，sdk算法等以应用的形式存在，并由提供商发布和提供支持，代理商可以加入共同推广，行业应用拓展，所有资源可以实现有控制的互联互通，通过发布订阅实现能力的共享，以数据流做为介质，自定义指纹授权管理。

2.自带流管理，支持多流共享，格式支持h264 h265 av1 opus yuv420等，1080p 4k分辨自适应，多屏幕虚拟屏幕个性化按需分配。1.基于串流的采集动态编码技术，支持软件GPU硬件编码模式，可变帧率，低延迟高画质带宽，游戏渲染也丝滑。6.加密迅捷的文件数据传输通道，拖拽 ctrl c v实现文件远程传输，剪切板内容远程交换。5.无人执守代理，支持键盘鼠标虚拟控制，支持锁屏登录界面，支持远程关机，开机自启动。4.物联网级设备管理机制，支持基于设备，组织的消息信令发布定阅。

3.支持多协议多编码接入，目前支持rtsp，rtmp gb28181 webrtc的按需拉流，拉流逻辑完全由客户端实现，可以做到端到端的自加密传输，支持annexb rtp h265 h264等视频的传输和播放，支持aac ，pcmua opus等音频的传输和播放，无插件支持h265浏览器播放，数据完全自主可控，方便接入tensorflow.js实现ai模型应用。1.多端互通，涉及服务器端，网页端，移动app端，微信小程序端，嵌入式设备端，各端的框架代码都是我无数个昼夜，辛苦构思，敲出来的。

直播是一种非常直观高效的信息共享模式，目前直播带货比较火，但我也不懂，现就我涉及的领域和实践做一些分享，目前我所做的直接互动分发系统在软硬件全系统闭环下，结合100ms级的低延迟，基本可以让人有深入其境的体验，但传统直播很难做到交互控制，比如桌面共享，远程仪器仪表操作，远程机器操作，所以直播结合远程协作控制又将用户体验提升一个新的层次，给信息化数字化带来了新的助力。

高性能音视频采集拉流推流编解码渲染存储引擎…

按需拉流是从客户视角来看待音视频的产品功能，直观，好用，为啥hls flv大行其道也是这个原因，不过上述存在的问题是延迟没法降到实时，通过一段时间的努力，结合自己闭环技术实现了h264 h265 aac pcma pcmu等音视频的rtmp rtsp gb28181地址的直接拉流播放，技术其实不复杂，但这里涉及了很兼容性和容错处理，自适应处理，每一个都涉及到前后台的实时交互和媒体流参数的实时识别和适配不同的传输通道，解封装，解码通道，渲染通道，这是一个需要大量场景来验证的一个苦差事，很多逻辑相关性的调配。

超低延迟，多窗显示，自适应编解码和渲染，高分辨低码率，还有微信小程序的标配，这些在现今的监控和直播中都成刚需了，中国的音视频技术人面临着困境，核心门户浏览器不掌握在自己手上，老师只讲即要又要还要，并且一专多能工资少，能白嫖绝不花一分钟，反正时间不值钱，于是就出现了各种开源抢占生态位，各种偷偷用开源搞成闭源闷声发大财，信息的和资源的不对对，导致市场极度扭曲，我就是在这种状态下，夹缝中求生存，抱着伟大的及永不磨灭的兴趣爱好，闹门造车，，搞三不像，各种投机取巧，消磨了时光和意志，留下一堆自嗨。

微信小程序自成体系，自身也带了很强的rtc音视频能力，但是他捆绑了他自己的服务，开发也相对受限于他的api。

最近利用自己以前学习和用到的音视频知识和工程技能做了一个android的sdk,实现了本地流媒体ipc rtsp 拉流以及自带mip usb等camera audio节点产生的流媒体通过webrtc sfu的方式进行多对多级联发布共享,网状结构，p2p组网，支持实时渲染以及转推rtmp，webrtc,h264 h265 opus aac g711,均支持，在rk3568 android 11上多路1080p 30fps渲染转发毫无压力，请教大佬们有什么好的应用场景来适配这个技术。

go在流媒体传输领域也有很强大的生态和优秀的轮子，比起传统的ffmpeg这种大而全的库，可以选择性的用一些小巧强悍的go语言写的库来替代ffmpeg，比如rtsp拉流，笔者用ffmpeg在android下写了一个推拉流的播放器，但是由于ffmpeg自成体系，在灵活定制方面有一些局限性，于是尝试用go rtsp来代替ffmpeg的rtsp拉流。以下是go写的动态库源码，由于go的包管理做的特别棒，你可以用很少的代码实现一个多路拉流的应用。感觉比c++爽多了。

多媒体服务就是将推流进来的媒体流转发至消费的播放器，其中对于webrtc的媒体流主要是一个信令交互，然后建立连接后实现流的发布和向订阅的peer进行转发。webrtc track到来时发布流并向所有订阅本流的播放器进行转发逻辑。播放器跟服务器建立webrtc连接peerconnection。服务器跟webrtc设备端进行信令交互并建立连接。

一般多媒体服务器都是很少有信令或者信令比较弱，主要是考虑信令跟业务强相关，但是iot领域有非常需要一个很好用的信令组件，实现互联互通，又方便自定义，于是我选择了iot领域用得比较多的mqtt作为信令载体。类似消息机制的设计，将具体的信令和接收发送逻辑分离，方便维护。信令是一个自定义的命令字的传输和功能解析。基于json的传递message 结构。

stream 流是一种资源，也相当于生产者，供很多消费者peers来使用，stream跟peer是一对多的关系，它由多媒体流输入来产生，同时支持向livekit room发布流，需要消费的peer统一由pees 的map来管理，根据连接状态进行增删等操作。4、详细的方法实现如下，此构成了多媒体服务的核心之一，流的生成及消费和状态管理，以及连接的生成和状态管理，实现媒体的发布和消费，流就可以真正的流转起来了。简易的播放器，支持p2p及流媒体转发，支持rtmp及webrtc的转发。

pion具备并发性能，网络吞吐能力，以及SDK的完善度均可以支撑一般规模的应用，个人认为小团队创业公司首选路径就是采用好入门的生态完整的，社区活跃的开源代码库进行二次开发，享受生态带来的红利，在自己的实践中深入了解底层原理，然后再根据自己业务的需要逐步更改为自己的模块，不失为一条稳妥高效的技术路线图。............

利用webrtc的强大p2p能力，接合mqtt灵活的实时发布订阅广播能力，打造gb28181 rtsp rtmp webrtc等推流h264 h265 aac opus，实现树状，网状p2p组网，将iot实时数据及音视频数据融合在网络并发分发，按需消费，逻辑和网络路由由客户端定制，利用时序数据库tdengine强大iot大数据存储分析能力，打造内网布署，全网分亨的分布式系统，高效的为数字化应用提高强大的采集分发分析工具

随着浏览器的的开放,webcodecs更多解码能力得以释放，zoom模式也变得越来越有吸引力，端到端低延迟低码率，高画质AⅠ加持已经路径成熟了，目前本地h265端到端直播延迟进入100ms已经成为可能

浏览器作为计算机操作系统通用门户，非常方便的提供了访问互联网的功能，而且可以很好的结合业务拓展，为播放音视频提供很好的载体，比专用桌面播放器在方便性易用性的优势明显

支持了GB2818摄像头的推送转webrtc网页拉流，H264/H265据实现网页实时播放，本地测试有非常不错的低延时效果欢迎大家下载测试。

根据bilibili以及dash的启发，终于实现了h264/h265 aac fmp4码流的硬解播放，实现了wasm软解码以及mse硬解码的双支持，目前浏览器已经很好的支持h265播放了，高分辨实时音视频播放及实时帧处理成为可能，欢迎大佬技术指导交流

h265播放器主要针对webrtc的实时流，所以信令在里面是一个很重要的组成部分，由于业务的关系，需要自己将信令跟自己的系统进行深度融合，本播放器，主要针对大量分散设备的管理和p2p拉流，所以主要选择了mqtt这个极简有很灵活的协议作为信令传输的主要协议。

物联网时代，AI时代的到来，催生了各种应用场景的技术融合，适应实时流、支持多分辨率、多编码格式、低延迟、容易跟各种系统集成使用的播放器需求越来越迫切，在全球技术大变革，中美争霸的大背景下，我们小小的开发人员可以用自己的双手为中国的软件生态助力，国产实时音视频生态日渐崛起，我也要做其中一个小小的水滴，准备用自己的勤奋和大家一起打造一款好用的开源的实时播放器。2、支持H265 webrtc datachannel 拉流，wasm 解码 webGL渲染OPUS音视频 webrt拉流，做到了音视频的同步。

metaRTC 嵌入式webrtc p2p H265 播放器实现。采用wasm技术，metaRTC IPC 软件包 ，datachannel h265视频编码发送的函数，并实现了帧的解析。过程比实现本身的价值更高。

H265+opus在浏览器器中实现ipc硬编流的传输和播放，基本上达到了单路1080p,30fps的不掉帧，音视频的同步效果，采用了wasm simd优化，极简自定义传输协议，帧过滤，缓冲自调整，多任务后台运行，多解码器动态加载等技术，后续将偿试进行帧处理ai，帧编辑，音频可视化及分析，webcodecs,insertablestream,webtransport,gpu硬解接囗等商业化方向的探索，欢迎定制咨询和共同开发。合理延迟不掉帧流畅播放缓冲控制极致同步............

整个播放器开启两个worker，playerworker 和decoderworker,并通过消息进行worker间通信，可以理解成js下的多线程，很多UI和webrtc的api在worker里是没法使用的，所以在写的时候一定注意这个坑。播放器入口函数handleVideo()建立了 player worker 在player里面再建立decoderworker,同时启动webrtc信令交互建立p2p连接，打开H265data 传输的dc通道。

因为很多编码芯片基本上都是支持H264和H265的，VP9和AV1基本上硬件都不支持，大量的显示需要H265来减少流量，特别是4G应用，H265比H264 要少接近一半的流量。为了学习编解码和webrtc以及wasm相关技术,结合网上开源的播放器基础，重新实现了一个基于webrtc的播放器，编码是rv1126 的H265硬编，传输采用webrtc datachannel,信令采用mqtt,播放采用webgl,使用了多worker模式，数据采用指针传递和缓存模式。以下是核心的解码worker。........

rtmp协议作为直播姐的一大利器，周边生态很成熟，比如OBS这些直播工具，可以很好的满足网络推各种流，但是网页播放，传统一般是采用的swf播放插件，现在webrtc越来越流行，浏览器天然支持让音视频应用变得更加简洁高效，而且实时性也得到了不晓得提升。万能的开源给了我无穷的力量，没有什么是ctrl c v解决不了的，于是稍做整合就出来了一套效果不错的直播推流软件，想给女朋友同步分享看剧的朋友有福了，show me your code以上代码，就是简单的实现了AAC转opus的关键一环，将无声的世界变得更

https://github.com/soloIife/yolov5_for_rknnhttps://github.com/airockchip/yolov5

https://github.com/Tencent/TNN/blob/master/README_CH.mdTNN：由腾讯优图实验室开源的高性能、轻量级神经网络推理框架，同时拥有跨平台、高性能、模型压缩、代码裁剪等众多突出优势。TNN框架在原有Rapidnet、ncnn框架的基础上进一步加强了移动端设备的支持以及性能优化，同时借鉴了业界主流开源框架高性能和良好拓展性的特性，拓展了对于后台X86, NV GPU的支持。手机端 TNN已经在手Q、微视、P图等众多应用中落地，服务端TNN作为腾讯云AI基础加

1.支持rtsp