MBStudio Blog|

FFMPEG基于命令行方式进行RTMP或RTSP（以及最新的WHIP）推流使用很普遍，基本上在桌面或服务器环境（Linux、Windows）下，大家习惯于直接用命令行方式使用，方便移植和调整，包括许多NAS上的视频转码也大多这种方式。

问题：音视频不同步

命令行方式用的人多了，原始的C语言的API方式编码实现就变得稀罕了，基于你去市面上找不到一本正经讲这方面知识的教材或教程，网上的片段，由于FFMPEG最近版本变化非常快，很多都是过时或者“只输出代码不输出知识”——不讲原理，许多代码就这么稀里糊涂的带病上线，凑合用吧。所以许多多媒体、流媒体的应用或服务经常出现各自奇葩问题，大多是由于程序员一知半解搞出来的事。

这不最近有一个项目里，服务端是使用的ZLMmediakit，客户端是Android客户端调用FFMPEG 8.0 JNI方式，实现抓取摄像头、麦克风数据，使用h264mediacodec进行硬件编码，进行RTMP（H264+AAC）推流。

服务端声音和视频都收到了，但明显卡顿异常，用VLC直接播放，视频是实时的，但音频延时甚至达到10秒的问题，就这个问题，我们使用程序员的方式进行debug分析处理。

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

异常的：

仔细看这段代码并没有特殊：

1
2
3
4
5
6

navigator.mediaDevices?.enumerateDevices()
    .then(devices => {
      devices.forEach(device => {
        console.log(`${device.kind}: ${device.label} (ID: ${device.deviceId})`);
      }
    });

但打印出来就是 ：

最近在调试基于web的sip开发库（有sip.js和jssip两家），原理都差不多，都是通过SIP RFC的websocket扩展（SIP over WebSocket RFC 7118，标准情况下是UDP、TCP或TLS传输方式），通过ws消息传递标准sip消息（目前主流VoIP平台，例如：Asterisk,Freeswitch,Kamillo等均有支持），然后通过浏览器webrtc进行音视频编解码和rtp通信。
需求的来源也很简单，目前类似PJSIP的C/C++的sip开发库虽然已经非常成熟，但native开发始终是个门槛，尤其是界面开发（之前曾经开发定制过一款单exe的mbphone sip软电话，可以说80%工作量都花在界面上了，还是在使用了duilib库的前提下），现在想找齐Windows、Linux、Mac三平台都简洁好用的SIP软电话都非常困难，更不用说开发集成了，尤其是现在WEB应用和移动应用普及的时代，开发全平台的软件成本太高。

webrtc的开源平台和客户端sdk开发解决方案似乎很多，github一拉都齐活，但仔细试下来，由于webrtc的开放性并没有定义应用层通信协议，所以许多开发者大多是另起炉灶采用私有应用层通信协议，甚至ws+http混用，与标准程控交换机IPPBX、呼叫中心、视频会议等现有设施并不兼容（一般是通过这些Webrtc平台额外提供的sip网关进行转接，商用的zoom、腾讯会议也是类似解决方案）。

如果需要开发标准的SIP软电话，就需要开发5个原生的客户端（例如采用PJSIP，支持windows、Android、iOS、Linux、MacOS全平台），对于中小公司和个人开发者几乎不现实，所以视线还是回到跨平台特别是web解决方案上来。

早几年，各家开源sip通信平台对于websocket的支持还不太成熟，例如freeswitch当时实现的webrtc软电话方案，是通过verto方案折中实现verto就是一个私有的应用层协议，它并不与sip协议兼容，而且文档也不完备，除了直接使用它提供的verto软电话，并不具备太多个性化定制能力。
好在freeswitch最新1.10版本上，sip的websocket支持已经可用了，而基于javscript的sip协议栈例如sip.js和Jssip也非常成熟了，所以通过WEB实现标准的sip通信成为可能。

最近Github的白嫖Pages是越发的访问不稳定了，想使用CF的CDN加速一下，先正常托管DNS域名mbstudio.cn到CF上，解析mbstudio.cn和www到CNAME值meineson.github.io（只是启用了DNS解析，没打开Proxy代理加速开关，一切正常）。
github pages使用的是HEXO搭建，已经手工修改掉源码里的CDN缓存js文件，但还是慢的发指，git pages仓库的setting里已经启用了自定义域名（会在meineson.github.io的git仓库的根目录下自动创建一个CNAME文件，里面值就是自定义域名mbstudio.cn）。
回到CF上启用proxy，以为万事大吉，结果301无限死循环来了。
甚至直接输入原始的meineson.github.io也会立即被跳转到mbstudio.cn然后301死循环（另外的www也一样）。
尝试去git仓库后台删除自定义域名，即仓库里的CNAME文件被删掉，可通过原始meineson.github.io访问了，但再次通过mbstudio.cn自定义域名访问时，就提示404了。

简单分析了下原理：
因为无论是通过IP地址还是CNAME记录跳转到github pages的服务器（大概是4个ip地址，给所有用户共用），它都要检测被访问域名，如果git仓库没有设置自定义域名时，它只认meineson.github.io这个原始二级域名，而如果设置了自定义域名，访问目标是二级域名meineson.github.io时，会被强制301重定向到自定义域名mbstudio.cn（因为CF没启用代理，还是回到github服务器上）再获取网站内容。

所以当CF开启CDN加速后，理论上是用户输入自定义域名mbstudio.cn访问时，CF会返回它的随机CDN服务器地址给用户而隐藏实际地址，用户实际访问的是应当是CF服务器上缓存的HTML文件，会非常快速。

但问题出在CF的CDN服务器转发了用户的请求到达github服务器时，github服务器并没有识别到被访问域名是mbstudio.cn，并没有直接返回网站内容HTML数据，而是返回301让以自定义域名重新访问github服务器，CDN服务器也直接转发了该301回复，用户浏览器收到301再次访问301目标mbstudio.cn时，再次到达CDN服务器重复上述逻辑，造成死循环……

由于截至目前仍未找到有效的解决办法，取消CDN可以恢复github pages的访问但还是速度感人，暂时通过CF的Workers & Pages功能，新建一个Pages发布，直接连接github仓库，自动克隆github的hexo源码仓库，build命令使用：

问题来源

有些电脑在安装完操作系统和应用软件后，功能正常很稳定，很长时间是不需要作改动的，也不关心上面产生的日志之类的无用数据。

• 但有时就是手贱一不小心删了、改了东西，重启一下，机器启动不了了
• 电脑频繁被直接断电开关机，时间不长就再也启动不了，甚至硬盘损坏了

如果直接把根分区”/“在/etc/fstab里给干成ro了，那么大概率各种问题就出现了，甚至无法启动（有虚拟机的可以做个快照，来修改试验一下报告一下更新进来），所以才有了下面这些方法。

极简懒人版方法1：

• 前期准备

前两篇文章，分别架设好了小程序商站的后台服务端（提供小程序的数据接口，存储商品和交易信息等等），编译并且在手机上成功打开了测试版小程序，成功拉取到了服务器上的测试数据。

本篇开始，为“真实”运营进行下一步动作。要运营，肯定不能光看那些测试数据，要发布真实的商品和真实的支付订单以及快递流转，所以需要一个后台管理界面，我们选用的海风小店提供了两种数据管理方式（其实是3种，你是大神的话可以手写sql直接管理数据库），其中一种是部署在本地电脑上，直接在电脑浏览器里打开管理界面（相当于用mysql数据库管理软件的可视化版本），优点是方便和安全（真安全啊，没其它动数据库数据的手段），缺点是只能一台电脑上管理，所以综合大多数人的需求，我们在之前那台作小程序服务端的服务器上部署（也可以是一台全新的服务器，做到管理界面和数据分离，读者可以举一反三，我们现在只讲最简单、通用的）。

• 代码获取

上文提到，本地管理使用的是hioshop-admin源码，我们需要架设在服务器上通过web访问管理，需要用到hioshop-admin-web（
https://github.com/iamdarcy/hioshop-admin-web）。

接上回，服务器搭建好后，我们开始调试小程序端，前提是你有一个已经可以正常工作的开发环境，这里不“0基础”培训了。

• 下载代码

直接zip打包下载海风小店微信小程序源码：https://github.com/iamdarcy/hioshop-miniprogram ，解压到开发文件夹。

• 微信小程序开发

导入代码，修改config/api.js中的ApiRoot为你的服务器地址，即上篇文章中提到的最后打开的那个网址,例如 http://meiwutea.com 。
先CTRL+SHIFT+P方式编译代码，在本地电脑上预览一下，确保代码正常。

多说一句，阅读提醒！

有点标题党了，但不夸张。实现“1天搭建”的前提是有Linux服务器命令行操作基础能力、git指令，懂Docker，有基础的微信小程序开发hello world水平；“免费”的定义是不为这个小程序商店额外付几百几千甚至上万的年费、软件服务费，开店所需要的服务器、域名、微信小程序认证费、微信支付的开通等等费用还是要的，如果这段话大部分内容你看不懂，那么大概率你没办法“1天”和“免费”搭建出来一个卖茶的小程序，该花的钱还是得花，找专业的小程序服务商吧。

• 前言

众所周知（笑），作为程序猿，最近卖茶了，除了淘宝店顺利开张了，其它都多多少少有各种门槛（说人话就是要钱），包括但不限于企业营业执照，食品经营许可证以及各种保证金、服务费……

一怒（笑）之下，打算翻出老本行还是自己搞吧，综合考虑了下，选择在微信小程序上开店（虽然微信官方也有企业公众号开店、视频号开店和已经停滞的微信小商店等好几种模式，但腾讯搞电商总差点意思……综合考虑了下，还是小程序最具备推广前景，也能兼顾后面自己搞独立APP）。

近日跟踪分析一个程序，其特征为，在运行过程中，可以毫无征兆的随心所欲的崩溃，而且无论是debug跟踪还是dump分析，出错的地方的代码都是完全没问题。

经过排除了所有可能的外部链接的各种lib库带入的问题的原因后，问题重新回归到应用程序代码上来，经过反复定位，由于程序最终出错都是发生在另外一个稳定可靠的lib库在执行某代码功能时分配内存时报“HEAP: Free Heap block 44734b8 modified at 4473580 after it was freed​”这类错误，字面上就是说，有一段heap堆内存被错误的在已经释放后又被操作了，即俗称的C/C++万年老大难“野指针”问题。

这种问题一般发生在内存被重复释放（释放后指向这块内存的指针又被使用，然后在另一个地方又被释放），或者哪块内存被“越界”操作了（数组只有10，却写了11的位置）等等情况下，但操作系统的机制决定了代码在执行这些操作时​，它不报错，直到这块内存又被人使用时，好了，它bi的一下崩掉了，但这时候通过回溯函数调用堆栈stack只能看到正常执行内存分配的场景，也就是你通过正常的调试跟踪和抓dump根本没用，原先想用之前在linux下分配内存泄漏的memleak函数库来分析处理（它的原理就是替换系统所有malloc, free等函数，在执行这些操作时记录一下分配和释放并定时或手工打印出来，这样程序跑一段时间，如果有哪个分配的内存应该释放的但还能在打印日志里看到，这块内存就是泄漏了），但考虑到一来这是linux下的库要移植，另外这个windows程序大量调用了外部lib库，全部替换成memleak进行内存分配处理工作量太大，寻找现有方案。

好在这个问题不是我一家遇到，微软MSDN上已经有相应工具提供（不过网上的大量日志已经过时，下载不到），类似工具有Gflags（包含在Debugging Tools for Windows里）及其它类似工具，可以通过下载windows SDK安装时选择安装这个工具就可以找到，然后这个工具是一个命令行，通过gflags.exe /p /enable xxxx.exe /full打开（当然还有一些额外参数，这次调试工作里没用到），通过gflags.exe /p /disable xxxx.exe关闭，其实它没做什么复杂工作，只是修改一个注册表项，修改了操作系统的Heap堆内存的分配机制。

其核心原理简单分析了一下就是，原先malloc只是在heap堆里分配一块内存，然后free后还给系统，但gflags操作后，这个程序再申请内存时，除了原有一块内存，还会紧接它又分配一块额外的内存但标识为noaccess不允许访问的，而且free后也同样给这块内存打上noaccess标识，这样，再重复上面我们描述的问题，如果出现内存已经释放后又来用它（写它），立即就会触发异常崩溃，同样，如果想越界访问超出已分配内存大小的区域，也会立即触发崩溃，这样，这方便我们立即定位到真正的问题点，而不是等到内存再次被申请时才发现内存异常了，一般能够让你立即发现问题了——本次调试的程序最终发现问题点出在一个动态分配的数据结构在通过windows消息发送到接收端时，错误地将整个消息大小当成某一个字符串大小而进行了尾部设置为0的内存写操作，最终导致了libcurl这个内存大户在频繁分配内存执行curl_easy_perform时频繁导致程序崩溃，一直错怪了libcurl以为它不稳定，最终还是跟它毫不相关的另一个位置的代码的一个小小的p[n] = ‘\0’配值操作导致了整个程序的不稳定。

新闻链接：
http://www.cnii.com.cn/telecom/2014-11/06/content_1473626.htm

看了一下，移动还是抛不开自身利益，现在公开的信息看，即使它上线规模化应用后，差异点还是仅仅与普通手机间短信免费（移动网内，但易信已经和其它运营商免费短信了好吧……），而图文类信息正好是微信的强势，反而是实时语音以及与普通电话互相直接通话这块微信做不好也做不到，移动还是下不了决心做（易信现在也有类似问题，用给电话机留言的奇葩方式实现，有点象手机以前给固定电话发短信，固定电话能接到电话听到机器读的短信内容），移动甚至连想法都没有（但腾讯可以用语音对讲等替代功能，潜移默化改变用户的习惯，等网络进一步提速后，用户会象习惯了用微信替代短信一样，用QQ、微信的VoIP语音代替普通电话时，移动到时想免费都没人用了）。

做平台，特别是面向普通消费者的平台，移动一直以来都没那个本事，飞信最火爆的时候，那么多海量的学生用户，它都没能建立起一个社交圈子，只是用免费短信的功能做了一个工具的角色，但这个工具也没做好，软件做的非常差，第三方开发的精简版的只用飞信发短信的工具其实更流行，所以飞信被抛弃的时候非常快，很快就无声无息没人用了。

当然，只做工具也没什么不好，只要这个工具好用，即使在all in one概念流行的国外，imessage（苹果官方的内嵌在ios上的图文和视频、语音）和whatsapp（只用来发图文消息，而且还是收费软件）这两个只做工具，也一样有大量用户，而在国内，许多人其实并不喜欢qq微信的大而全，如果作为移动运营商推出的一款免费（或收费合理）的工具，包含常用的文本、图片、语音（实时）、视频并且使用可靠，也还是能占领一块市场的——只不过以移动的风格，短期内肯定不会放开和普通手机、电话的通讯，再加上人为的决策大量模仿微信，变的太象微信了，就吸引不了用户了——还是比如易信，现在已经模仿不下去了，已经开始参考网上文章的建议的去转型做游戏分发平台了（又或者那些文章就是易信自己发出来探探大家口风的，一家“这么大”的企业，不可能照着网上文章的建议做事吧，哈哈，结果大家都没反应也没人讨论说好还是不好，因为没人关注它，好囧，更囧的是阿里的来往吧…………）。

个人意见：