本软件工作室承接基于ffmpeg的二次开发软件项目
可提供转码，流媒体录制, m3u8切片, HLS直播, 音视频解码播放等相关开发。
项目金额 10000 RMB起。具体金额具体商谈，联系方式请点链接
1. libRtspClient Demo下载测试：
RTSP/RTMP流媒体播放库，可支持边录制，边播放。采用多线程支持多任务拉流。底层采用live555和ffmepg最新版本，可轻易支持android等平台。
RTSP支持onvif的用户密码认证。
编解码目前支持：视频支持H264，H265， 音频支持aac。
Windows下demo程序下载
2. Android下demon已可下载测试, 目前仅支持arm硬件架构，android[......]
本软件工作室承接基于Live555的二次开发软件项目
RTSP服务端：可提供TS流直播，点播, mp4格式扩展的直播和点播, 各种定制的音频和视频流组合流的流媒体服务。
RTSP客户端项目包括：录制RTSP流媒体，存储文件(格式为mp4或者ts).
不管服务端还是客户端，可提供双视频流或多视频流以及多音频流的流媒体扩展。
包括但不限于：H264 + h264 + aac 3个以上track的RTSP流, 或 H264 + mjepg + aac 等3个以上track的RTSP流, 或者H264 + h263 + aac包括3个以上track的RTSP流。
可灵活定制推送多track,多种编码格式混合的流, 以及录制多种编码格式混合的mp4或者ts格式文件[......]
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目录下的的都[......]