经过一段时间尝试，暂时放弃FFMPEG WHIP，过段时间再回来看吧，它目前阶段有几大致命问题： ICE协商机制非常弱，无法正确解析流媒体服务器返回的TURN/STUN服务器信息，如果服务器或客户端在NAT后面，无法正确建立连接。 编码只支持H264和OPUS，虽然可以使用Android MediaC...

由于Electron官方编译Linux版本不支持VAAPI编码，需要自行源码编译，这个工作还是有一些挑战性，首先是硬件需要8G以上内存，200G左右硬盘，以及10M以上的国际互联网访问通道。 可能因为各种原因，好不容易下载好的120G源码，在某台机器上由于硬件问题无法编译，需要更换机器，如果反复重复上述工作，都将...

经过与ChatGPT反复探讨（挑战）与实机测试，目前官方Chrome对Linux平台的GPU硬件编解码支持度还是可以的，最新的141.0.7390不加任何启动参数启动，已经可以支持主流的H264，H265以及VP8，VP9的硬件解码： 带上启动参数： 1google-chrome --enable-featur...

继解决了Android Mediacodec编码H264码流下降的问题后，码流上来了，WHIP推流也一如既往的奔溃了，毕竟是刚发布几个月的“试验性”功能…… 话说FFMPEG为了抢市场，这个试验功能推出的也够仓促的，好多参数全部写死，视频只支持H264，音频只支持OPUS并且强制2声道48000Hz采样，啥V...

AI编程哪天真能分析解决问题才是生产力，不然还是渣渣…… 记最近一次分析视频清晰度的问题，想使用FFMPEG最新的8.0版本中带的WHIP来试下“0延时”的推流，测试了RTMP和RTP_MPEGTS都是正常的了，但到了WHIP下面还是各种写包失败（虽然它的底层还是调用的SRTP来发送的），暂时还没空继续研究它...

FFMPEG基于命令行方式进行RTMP或RTSP（以及最新的WHIP）推流使用很普遍，基本上在桌面或服务器环境（Linux、Windows）下，大家习惯于直接用命令行方式使用，方便移植和调整，包括许多NAS上的视频转码也大多这种方式。 问题：音视频不同步 命令行方式用的人多了，原始的C语言的API方式编码实现...

最近在给MBWebPhone增加音视频设备配置功能界面时，发现在浏览器中正常但NWJS封装的APP中异常的bug——呼叫正常，但设备枚举为空白。一开始以为是nwjs的bug，但翻遍他们的社区，报告同样问题的解决方案是给出了–use-fake-ui-for-media-stream方式启动，这样能正常显示出设备列表...

最近在调试基于web的sip开发库（有sip.js和jssip两家），原理都差不多，都是通过SIP RFC的websocket扩展（SIP over WebSocket RFC 7118，标准情况下是UDP、TCP或TLS传输方式），通过ws消息传递标准sip消息（目前主流VoIP平台，例如：Asterisk,F...

最近Github的白嫖Pages是越发的访问不稳定了，想使用CF的CDN加速一下，先正常托管DNS域名mbstudio.cn到CF上，解析mbstudio.cn和www到CNAME值meineson.github.io（只是启用了DNS解析，没打开Proxy代理加速开关，一切正常）。github pages使用的...

问题来源有些电脑在安装完操作系统和应用软件后，功能正常很稳定，很长时间是不需要作改动的，也不关心上面产生的日志之类的无用数据。 但有时就是手贱一不小心删了、改了东西，重启一下，机器启动不了了 电脑频繁被直接断电开关机，时间不长就再也启动不了，甚至硬盘损坏了 如果直接把根分区”/“在/e...