superxxd的专栏

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

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

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

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

本应用采用增量式编码器进行速度和里程的精确测量，在软件设计上采用中断方式采集编码器输入的脉冲信号，本例的脉冲转一圈输出2000个脉冲。采用M/T测速原理，利用PIC32的定时器作为时间参照系，与采集的脉冲数一起进行比例运算，得出实时速度，并可以实现里程的累计预算。应用于实时测速和里程双测量的应用，大量应用于速度校正，里程计量，恒速控制等工业测量控制场景。

嵌入式系统往往会有模拟信号的采集，比如模拟传感器温度、压力、流量、速度、光强等模拟量，经过放大整形滤波电路后送给ADC芯片，将电信号转转变成离散的数字量这个过程称之为AD采样，AD采样应用广泛，普遍遵循采样率3倍于信号变化频率的法则，也就是说我们采样的时间延迟在1/3信号变化延迟即可得到完美的信号变化特征。

多媒体服务就是将推流进来的媒体流转发至消费的播放器，其中对于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的转发。

随着浏览器的的开放,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。........

在万物互联的时代，多平台融合的时代，选取合适的信息交互协议也值得非常耐心的分析，对比，取舍。MQTT本为物联网而生，轻巧灵活的架构，安全稳定的传输，自带设备管理的属性，成为我处理远程控制信令系统的首选，在使用过程中，可以灵活的实现分组授权，确保安全性和灵活性鱼和熊掌皆可得。信令交互设计的核心数据结构，结合控制信息，将信令和通用控制自定义协议融为一体，利用MQTT订阅发布机制实现 浏览器，嵌入式平台，windows,linux平台，设备与设备间，设备与平台间相互交互，互联互通。通过远程控制调试设备输出。..

webrtc是实时音视频传输的利器，除了audio /video track的传输外还有datachannel可用于数据和信息的实时交互，在设备和浏览器间建立一个p2p通道，利用mqtt作为信令，通过对设备端rtsp服务器推流进行转换实现视频的采集，另外利用datachannel 发送浏览的监听的鼠标键盘数据给设备实现控制受控机的鼠标键盘，从而实现远程桌面控制。没事的时候自己diy一个远程控制设备，增加自己学习webrtc 和go语言的兴趣，两全其美。android系统控制。手机对Win10桌面控制。...

上篇文章说了风头正健的pion生态之livekit,现在轮到pion生态第一个sfu ion,这个由国内大佬鱼大等主持开发两年多开源项目，为国人乃至开源社区普及pion起了至关重要的作用，得到了Sean-Der的大力支持，也汇集了众多高手加盟，livekit的风格也深受其影响，下面是发布ion的习作，望各位大佬指正。.........

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

metaRTC 嵌入式版本是采用纯C语言实现，采用了几个著名的通信库,日期在rv1126上实现了硬件编码发送，以及pcm语音采集发送，效果跟主流的pion和kvs毫不逊色，而且采用了多线程模式反复memcpy,如果尽量采用零挎贝技术，换用mbedtls应该还有进一步提升的空间，延时本地局域网87ms左右，效果还是很不错的。......

YangAudioEncoderBuffer2 其实就是 YangAudioEncoderBuffer2 ，只是我拷贝了YangVideoEncoderBuffer2 的内容改了一下叫法，第一步为我们应用层写缓存打下了基础，接下来，一定要搜一下out_videoBuffer ，凡是他干的，out_audioBuffer也干一遍，主要就是初始化和跟底层rtcsession的发送缓冲区建立联系。好了，欢迎各位大佬批评指正。慢慢的就会ctrl c +v了。好了，是不是很简单，主要是我只会ctrl c+v。....

webrtc的datachannel是实时数据传输，特别是控制信息或者交互信息的一个高效简洁安全的传输方式，在交换SDP时加入m=application webrtc-datachannel 相关内容，协商一致后即可实现通信，为了datachannel通道可以传输byte类数据也可以传输string类字符，所以可以灵活的实现自定义的数据交互。metaRTC是新开发的嵌入式webrtc，有很多功能和api需要进一步开发完善和摸索，也需要更多的人参与进来，大家一起学习进步，让社区更强大。...

metaRTC实现了sfu和p2p两种模式，支持srs和zlm两种推送已经p2pserver模式，如果要实现自己的信令系统其实也比较简单，最近实现了metaRTC的基于mqtt的信令，同时可以进行p2p和服务器转发，方便自己的设备和系统融合，现就信令系统的流程以及涉及的函数进行一个梳理如下，按此流程可以实现自己的信令系统。基于服务器转发的flutter跨平台应用，.....................

最近杨总的metaRTC很火（gitee.com/metaRTC/metaRTC），也决定将以前的一些应用移植过去，拥抱国产生态，在适配过程中，发现测试还是比较麻烦，不是ffmpeg,就是需要IPC得硬件版子，能在pc上实现初步调试是非常有必要的，于是通过一番查找和恶补H264编码格式得相关知识，做了一个通用的获取H264帧的函数，话不多说，直接上代码，获取某帧的段地址指针很相应长度偏移量。发送至metapeerrtcsession缓冲器。循环发送H264文件帧线程。.........

在go语言中使用viper之类的库很方便的处理yaml配置文件，但是在c语言中就比较麻烦，经过一番思索和借助强大的github,发现了一个libyaml c库，但是网上的例子都比较麻烦，而且比较繁琐，就想法作了一个相对比较容易配置的解析应用，可以简单地类似viper 的模式进行配置实现不同的配置文件读取。如你的配置文件很复杂请按格式修改KeyValue 全局变量，欢迎大家一起完善库请自行下载 GitHub - yaml/libyaml: Canonical source repository for Lib

远程办公利器 kvm3.0不用装软件就可以通过网页使用远端电脑桌面和网内ssh，还可通过共享网盘进行文件分享，关键是点对点，可以自己私有布署和二次开发，欢迎大家来找茬。

Use gRPC interceptor for authorization with JWT - DEV Community

第一种解决办法：采用ln链接方式进行处理ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock因为是从tmp目录下，所以有可能/tmp下的这个文件将会被删除第二种解决办法： 进入到‘/usr/local/mysql’目录下，找到my.cnf文件打开，在最后一行下面加入一下内容,因为“[mysqld]”是针对服务端进行设置，[mysql]”是针对客户端访问进行设置；[mysql]socket=/var/lib/mysql...

嵌入式Linux MIPI接口LCD调试-关于DRM显示与应用调试的干货浓缩 - 云+社区 - 腾讯云 (tencent.com)linux中基于DRM的图形显示系统概述libdrm-modetest原理及图显系统验证方法以下的这些概念和操作都是本人在实践的过程中觉得对调试有用，所以就记下来了，接下来我们来简单的了解一下：1、有关DRM的一些基础概念1.1、Connectors就是屏幕，比如主控芯片通过HDMI、MIPI DSI，分别接2个屏幕显示，就会有2个对应的Connectors

tdengine 2.20版发布直接支持纳秒时间戳了，毫秒、微秒、纳秒，建库时需要用 precision "ms"、precision "us"、precision "ns" 来进行标注，如果传入的时间戳不满足位数位数要求则报错。做了一个简单的格式转换函数，利用string 切片实现了时间戳字串长度截断和补齐，解决时间戳不统一的问题。func (taosd *TDengineDataSource) getTimeStampWithPrecision(tls string) string { z..

开源https://github.com/xiangxud/kvmweb

https://github.com/rust-in-action/code

boost-program-options-1.53.0-27.el7.x86_64.rpmgalera-4-26.4.3-1.rhel7.el7.centos.x86_64.rpmMariaDB-client-10.4.11-1.el7.centos.x86_64.rpmMariaDB-common-10.4.11-1.el7.centos.x86_64.rpmMariaDB-compat-10.4.11-1.el7.centos.x86_64.rpmMariaDB-server-10.4.11

官方文档：https://hellosean1025.github.io/yapi/devops/index.html1、环境要求：nodejs（7.6+)mongodb（2.6+）2、新增目录并进入mkdir /usr/local/yapi3、克隆项目；git clone https://github.com/YMFE/yapi.git vendors //或者下载zip包解压到 vendors 目录（clone 整个仓库大概 140+ M，可以通过gitclone --depth=1 ht

为了实现gin API接口返回的时间格式符合andriod等的习惯，方便解析，需要对Time的json解析进行重写，由于牵涉到了gorm的数据类型，所以只能简化操作在获取到数据object或转换成自定义格式，代码如下package timeimport ( "time")type Time time.Timeconst ( timeFormart = "2006-01-02 15:04:05")func (t *Time) UnmarshalJSON(data []byte)

地址https://gitlab.freedesktop.org/pulseaudio/webrtc-audio-processing/库abseil cpp下载代码：git clone https://github.com/abseil/abseil-cpp.git编译代码：cd abseil-cppmkdir build && cd buildcmake .. -DCMAKE_INSTALL_PREFIX=/usr/ -DCMAK..