pjsip移植到stm32(freertos系统)
项目目标：基于stm32 H750构建带SIP通话的UI应用系统
单片机硬件： stm32 H750 主频480M
实时操作系统：freertos
开发工具：keil uVison 5.23
编译器: armcc
编译的包：freertos + lwip + FreeRTOS_Plus_POSIX + pjproject-2.7.2 + emwin 5.x
pjsip pjporject-2.7.2编译方法步骤：
1.在linux ubuntu系统下安装arm-none-eabi编译工具链，进行配置和初步编译
2.把已经配置好的pjporject-2.7.2目录，拷贝到windows中，修改各个子目录的makefile文件，把编译器修改为armcc，编译和连接选项修改为armcc适配的选项。
把makefile文件中include路径目录修改为windows下的armcc系统目录或者keil uVison 项目工程目录，然后反复解决编译错误。建议去除makefile中所有的测试程序的编译链接步骤。
3.在windows中安装msys32开发包，在msys32命令行中利用msys32的m[......]
编码器及解码器音视频同步技巧
最近在海思3531D平台上重构了5年前写的编解码器代码。丢掉了很多为了实现音视频同步而写的很多冗余算法。任何时候都要遵循简单为美的原则。
无论编码端还是解码端，在音视频同步中，选定音频的pts为基准。原因是音频对pts的连续性更敏感，视频慢1/3 frame time或快1/3 frame time，人眼觉察不到。
一言概之：音频pts按帧率计算累加，视频pts在按帧计算累加基础上，再加上一个适当波动值进行调节（可以是正，或者复数，波动值一定要小于 frame time）。
编码器中音视频同步算法：视频的pts要以音频的pts为基准， diff = video_pts – audio_pts; 确保视频pts在绝对值范围内波动，例如diff超过正负100毫秒，适当增加1/3 frame time, 或者减少1/3 frame time即可。
解码器中音视频同步算法：收到rtp帧，即获取系统当前时间作为pts， 音频马上解码并喂给硬件底层buffer，视频则当pts大于音频pts才喂给底层硬件解码bufer即可。
在此算法下，音视频连续工作1个月，编解码器的音视频都是同步的。
算[......]
windows下内存randisk 临时目录初始化脚本，备案一下
gpedit打开后，目录[windows设置]\[脚本(启动或停止)\启动]下选择该脚本
C:\WINDOWS\System32\GroupPolicy\Machine\Scripts\Startup\myrandisk.bat
mkdir B:\TMP
mkdir B:\Chrome
mkdir B:\Build
mkdir B:\Firefox
mkdir B:\Other
mkdir "B:\Other\Internet 临时文件"
mkdir "B:\Other\Edge"
del /F /A /Q C:\Users\hzb\AppData\Local\Microsoft\Windows\WebCache\*
rmdir C:\Users\hzb\AppData\Local\Microsoft\Windows\WebCache
mklink /D "C:\Users\hzb\AppData\Local\Microsoft\Windows\WebCache" B:\Other
del /F /A /Q C:\Users\hzb\AppData\Local\Microsoft\Windows\WebCache\*
rmdir C:\Users\hzb\AppData\Local\Microsoft\Windows\WebCache
mklink /D "C:\Users\hzb\AppData\Local\Microsoft\Windows\WebCache" B:\Other
mkdir "D:\VCTMP"
mklink /D "B:\TMP\VC++" "D:\VCTMP"
copy /Y "C:\Users\hzb\AppData\Roaming\Scooter Software\Beyond Compare 3\MyBCState.xml" "C:\Users\hzb\AppData\Roaming\Scooter Software\Beyond Compare 3\BCState.xml"
live555的RTPSink获取丢包率
当我们用live555用作rtsp client接收rtp包时，有时候想获取当前rtp 通道的丢包率，用来判断网络状况。如何获取当前的丢包率？
可以关注rtcp协议中的2个字段：1. 直接取fraction lost字段，占8bit位，百分百计算方法为raction lost字段除以256得到。
2.取cumulative number of packets lost(累计丢包总数)字段，可以定时取这个值，根据前后2次的差值自己计算丢包率。
关注live555中对应的RTPSink.cpp源码，其中对应的2个成员变量为：fPacketLossRatio和fTotNumPacketsLost，可以搜索一下源码。注意fPacketLossRatio是没有除以256的。
可以从RTPSink的fTransmissionStatsDB成员变量中得到fPacketLossRatio和fTotNumPacketsLost值。
Live555用作标准的RTP发送和接收库
live555很多人用来做rtsp server或者rtsp client，其实也可以单独用作通用的rtp库。笔者就是对其进行稍作封装，命名为CRtpRecevier和CRtpSender类。这样就可应付很多rtp处理。
封装后基本可以一劳永逸的移植到各个平台上使用。live555支持的payload type比较全面。各种流行的媒体rtp封装都支持，不需要自己进行分帧和特殊处理，省很多事情。
代码性能和延时都有保证。音视频可小于80毫秒。
1. 用作rtp接收，可以参考我以前的博文
发送的核心逻辑是构造媒体的sdp字符串，然后live555内部会分析这个文本创建不同的解析类实例
Live555通过SDP文本信息实现对RTP的接收
2.用作rtp发送，基本逻辑如下
a. 构建一个数据源类
我这里命名为ByteStreamQueueBufferSource
实现一个以队列为数据源的通用类， 从FramedSource派生，可供其他类使用，用作音视频直播的数据源。
注意，该类参考live555原有的类ByteStreamMemoryBufferSource和ByteStre[......]
本软件工作室承接PJSIP开源协议栈相关的SIP客户端快速开发
提供基于pjsip开源协议栈的SIP客户端，包括SIP嵌入式产品或android平台SIP APP开发。音视频延时小于80毫秒。视频支持h264，音频支持pjsip支持的编码：g711,g722,speex,g729等。
具有MicroSip二次开发和基于海思3531，3536嵌入式平台的sip终端产品开发经验。嵌入式或android下，可通过在协议栈中增加虚拟的音视频dev实现硬编码硬解码。
项目金额 15000 RMB起。具体金额具体商谈，联系方式请点链接
本软件工作室承接Windows下的音视频流媒体软件快速开发
提供基于Windows下的音视频相关的播放，采集，流媒体，RTP相关软件开发。界面基于VC++ MFC。 基于ffmpeg H264或H265软编软解，AAC，G711，G722，G726等音频编解码等，性能绝佳，延时小于0.5秒，辅以调用ffmpeg转码及live555提供流媒体推送或拉取，确保项目开发周期短。音视频延时小于80毫秒
项目金额 15000 RMB起。具体金额具体商谈，联系方式请点链接
安装Randisk驱动后，Win10应用商店报错 0×80070057
最近买了新电脑，用的是win10，为了优化性能，安装了randisk驱动，结果安装了randisk驱动后，Win10应用商店安装老报错，错误码为0×80070057，找不到任何办法，好不容易在国外论坛上看到了是安装randisk引起的，如是禁用了randisk设备，然后重启，问题真好了！win10下的坑很多。
我用win10后至少遇到了三个坑：
1. randisk引起了APP stroe 老报错0×80070057，
2. 修改windows用户名后, windows update 老失败。解决办法：把windows用户名修改回去就好了。
3. 安装了USB转VGA和HDMI驱动后(Fresco Logic USB VGA Display)，安装visual studio 2013，visual studio 2015， visual studio 2017都会出问题，无法正常运行，
4. 无法安装.net framework 3.5，后面用dism命令才安装好
Live555接收RTP的Jitter Buffer机制(Live555 Rtp Receive Jitter Buffer)
用了Live555 5年了，今天想找一下它接收RTP的防网络抖动的处理机制，看看其jitter buffer缓存时间到底是多长，追踪源码，如愿以偿。
ReorderingPacketBuffer类就是其对接收的RTP包根据seqno序号进行排队的缓存队列，live555的缺省队列缓存是100毫秒，注意代码注释default reordering threshold: 100 ms；
具体代码如下：
ReorderingPacketBuffer
::ReorderingPacketBuffer(BufferedPacketFactory* packetFactory)
: fThresholdTime(100000) /* default reordering threshold: 100 ms */,
fHaveSeenFirstPacket(False), fHeadPacket(NULL), fTailPacket(NULL), fSavedPacket(NULL), fSavedPacketFree(True) {
fPacketFactory = (packetFacto[......]