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，可以搜索一[......]
Live555用作标准的RTP发送和接收库
live555很多人用来做rtsp server或者rtsp client，其实也可以单独用作通用的rtp库。笔者就是对其进行稍作封装，命名为CRtpRecevier和CRtpSender类。这样就可应付很多rtp处理。
封装后基本可以一劳永逸的移植到各个平台上使用。live555支持的payload type比较全面。各种流行的媒体rtp封装都支持，不需要自己进行分帧和特殊处理，省很多事情。
代码性能和延时都有保证。音视频可小于80毫秒。
1. 用作rtp接收，可以参考我以前的博文
发送的核心逻辑是构造媒体的sdp字符串，然后live555内部会分析这个文本创建不同的解析类实例
Live555通过[......]
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(1[......]
linux下用valgrind工具检查程序内存泄漏和程序性能优化
valgrind是linux下优秀的程序检查工具，优秀软件开发人员必备的瑞士军刀。其有很多工具包可以使用，具体可以参考官方文档和网络其他文章，本文仅限介绍用其进行内存泄漏、内存越界和程序性能优化。
linux centOS 6 下可以通过yum安装valgrind
yum install valgrind
1. 内存泄漏检查和内存越界检查，执行以下命令,其中test为需要检查的程序名
检查程序test需要以-g调试参数编译，才能报告内存问题的准确代码位置。
执行完后，会得到相信的统计结果，主要分4大类：
1. 肯定丢失的[......]
gstreamer从包含RTP的pcap文件提取视频保存mp4文件（文件由wireshark抓取)
好不容易从stackoverflow网站找到通过gstreamer从rtp抓包文件中提取视频的方法，命令如下:
参数说明：
location=183.215.100.4_send_h264_rtp2.pcap为WireShark抓的网络包，包含有rtp流。
rtp端口为：pcapparse dst-port=3002
rtp流的参数为：application/x-rtp,media=video,clock-rate=90000,payload=109,encoding-name=H264
本地文件格式为mp4:mp4mux name=muxer
保存本地[......]
静态首页和WordPress组合做企业网站
受朋友所托，帮朋友新开的公司做了个网站，感觉很nice，网站为 湖南诺继生物技术有限公司, 网站内容挂载的是WordPress。
技术很简单，首页是挂上菜单和图片动态展示栏，菜单项挂到WordPresss子目录下，这样可以利用WordPress强大的后台内容发布管理能力。
WordPress的主题采用的是Prower, 我看中其风格简约，菜单大气，但其不支持二级菜单，我修改了这个theme，为其增加二级菜单点击显示功能。有需要的网友可以联系我。
AAC raw包增加ADTS头
AAC原始码流无法直接播放，一般需要封装为ADTS格式才能再次使用，本博主在android中用MediaCodec编码得到的AAC就是raw格式，为了保存为.aac格式，需要增加adts头，这样就可以通过vlc或者windows Media player直接播放了。现在把网上搜集的资料和代码总结一下，以备自己以后参考，也分享给有需要的同仁。
源码来自：
http://stackoverflow.com/questions/18862715/how-to-generate-the-aac-adts-elementary-stream-with-android-mediacodec
实现函数：
Live555性能优化实践
网上很多文章提到了Live555的单线程任务调度模式，在用作RTSP服务时，导致了在并发量较多或者磁盘性能不佳时会导致性能较差，并发数受限。笔者通过在做基于海思3531编码器和解码器的过程当中（提供基于2路H264+1路AAC的TS流编码（输入为RTSP TS流)和RTSP流媒体解码播放)，有以下2点收获，特分享给有需要的同仁。
优化1：同步读取数据源修改为异步读取数据源， FramedSource的子类的doGetNextFrame函数中不要阻塞等待数据源， 在无数据时可以重新增加一个定时器任务，延时再读取数据。在无数据时增加一个等待任务：
{
if(无数据可读){//延时3000微妙（3毫秒)再次读取数据
envir().taskScheduler().scheduleDelayedTask(3000, (TaskFunc*)DelayReadFrame, this);
return;
}
.....省略其他正常逻辑
}
static void MyFramedSource::DelayReadFrame(FramedSource *sourc)
{
source->doGetNextFrame();
}
优化2[......]
深刻理解Live555源码，掌握这把RTSP，RTP的瑞士军刀
我无意评价Live555的源码是否优雅易懂，但对于我这种C++设计模式应用不熟的IT老兵，还是很难直接通过阅读源码深刻清晰，一目了然的理解其中的调用逻辑。Live555中关于RTSP的Session，SubSession的概念，以及FramedSource和Sink的抽象都很不错的。但对于其任务单步调用机制，以及如何读取一帧数据及时发出一帧数据的全部逻辑， 真不容易得到清晰的处理逻辑。实践出真知，笔者本文就介绍一种通过运行时堆栈信息迅速理解关键代码和关键逻辑的方法。
先来观察本文尾部的GDB打印的堆栈信息，是笔者在实际开发中在Live555中扩展了mp4文件格式的支持，凡是ffmpeg_server目录下的的都[......]