这是之前参与的某个项目了，离开了近一年， 仍然没有听到量产的消息， 当初搭的软件框架也不知是否还有人维护； 其实我们本来就不是一家具有监控项目经验的公司， 由于主业经营惨淡， 总监找来一些其他门类的小方案来做， 其中就有这个流媒体监控项目；
// MAGIC1. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
按理说， 监控在意图像延迟的指标， 这个在 linux 平台上会有更好的表现， 上了 android 就得考虑 mediaserver 或者 AudioHAL/AudioFlinger/CameraHAL 这些模块引入的延迟， 基本不可能比 linux 指标更好； 但是咋说呢， 留给这个项目的时间不多了... 没有时间和人力来搞 linux 上的 camera 框架和 video 编码器了， android 是既有的已量产方案， 延迟比linux 差个200毫秒没关系， 上吧...
// MAGIC2. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
那我还能怎样， 我当然是上了， 先试的是命令行 ffmpeg -f video4linux2 -i /dev/video0 从摄像头采集图像再组播转发， 失败， camera 驱动的人告诉我目前 android 平台上的 v4l2 驱动不标准， 代码不好改... 好吧； // MAGIC3. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
那不考虑 ffmpeg 了，反正走 ffmpeg 软件 encoder 也会是个隐患， 直接 StagefrightRecorder 改两行代码走 RTPWriter 发包， client 端用 ffplay/vlc 播图像出来， ok 了？
No，No， 很快这个小项目的客户反馈了， 有音频需求， 而 RTPWriter 只处理 h264 裸流... 所以改吧， 改 MPEG2TSWriter 代码去发 rtp 包， 很快改完了, ok 了？
No, No, 很快这个小项目的客户又反馈了， 希望走 rtsp 协议， 这样他们的客户端就不用动了... 尼玛早说啊， 尼玛之前不是说客户端是我们给客户推荐吗，尼玛小客户不能太讲究流程啊...
所以这个 rtsp 怎么接， 在 MPEG2TSWriter 上按 wfd/stagefright 的 rtsp 代码来改？ 前车之鉴，这次我决定多问一声， 问问客户原先的 server 端是什么， 他们说是 live555 ...
好吧， 上 live555， mediaserver 的 MPEG2TSWriter 与 live555MediaServer 通过共享 buffer 传数据， 其他不多想了； 改好以后， client 端测延迟， --network-caching 设500毫秒， 整体延迟 800毫秒， ok 了？ // MAGIC4. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
No No， 很快这个小项目的客户反馈说， 某些操作后延迟会累积增大； 我试着复现， 秒表图像监控连续2个小时， 未发现延迟增大， 但随后接了鼠标去刷网页， 立刻重现了！
于是跟进mediaserver 与 live555 的共享buffer 的读写指针， 可以发现某段时间时， 会有读写指针距离的突然增大， 在此期间， mediaserver 写指针的更新明显速度大于 live555 读指针， 这必然会增大延迟； // MAGIC5. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
因此怀疑与编码器码率的突变有关， 首先在 Encoder server 端打印编码出的帧长， 如下图：
前十秒是计时器场景， 最后十秒是计时器场景， 中间约30秒做快速场景切换
横轴坐标帧数， 纵轴坐标帧长 // MAGIC6. DO NOT TOUCH. BY 冗戈微言
可以看到确实存在某些帧的帧长突然变大； 先不考虑编码器端是否正常，在这期间， live555 端的读指针控制， 也就是对数据的读取速度无法跟上写指针， 也不合理，启动 cpu performance 模式也无改善， top 显示的负荷也不高， 因此跟进 live555 读取数据的部分代码： // MAGIC7. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
--------- 可见 live555 再执行读取数据/发包操作的过程中， 会有主动的 delay ， 而这个 delay 值是根据当前已收到的包长以及上一帧的码率， 估算出来的， 如下：
具体估算逻辑还没有看懂， 但基本上是根据前一个帧的码率， 来计算这一次 188*7 字节所对应的 duration， 来决定下一个 188*7 数据应该 delay 多久去读；
先不论如何改进， 直接将 uSecondsToGo 的 delay 上限设为 500微秒， 好了... // MAGIC8. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
其实还有别的一些坑， 总之当时觉得心好累... 因为隐隐觉得这个客户不太靠谱， 这边投入这么多精力却无法体现在业绩上， 别是一场空... // MAGIC9. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
按理说， 监控在意图像延迟的指标， 这个在 linux 平台上会有更好的表现， 上了 android 就得考虑 mediaserver 或者 AudioHAL/AudioFlinger/CameraHAL 这些模块引入的延迟， 基本不可能比 linux 指标更好； 但是咋说呢， 留给这个项目的时间不多了... 没有时间和人力来搞 linux 上的 camera 框架和 video 编码器了， android 是既有的已量产方案， 延迟比linux 差个200毫秒没关系， 上吧...
// MAGIC2. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
那我还能怎样， 我当然是上了， 先试的是命令行 ffmpeg -f video4linux2 -i /dev/video0 从摄像头采集图像再组播转发， 失败， camera 驱动的人告诉我目前 android 平台上的 v4l2 驱动不标准， 代码不好改... 好吧； // MAGIC3. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
那不考虑 ffmpeg 了，反正走 ffmpeg 软件 encoder 也会是个隐患， 直接 StagefrightRecorder 改两行代码走 RTPWriter 发包， client 端用 ffplay/vlc 播图像出来， ok 了？
No，No， 很快这个小项目的客户反馈了， 有音频需求， 而 RTPWriter 只处理 h264 裸流... 所以改吧， 改 MPEG2TSWriter 代码去发 rtp 包， 很快改完了, ok 了？
No, No, 很快这个小项目的客户又反馈了， 希望走 rtsp 协议， 这样他们的客户端就不用动了... 尼玛早说啊， 尼玛之前不是说客户端是我们给客户推荐吗，尼玛小客户不能太讲究流程啊...
所以这个 rtsp 怎么接， 在 MPEG2TSWriter 上按 wfd/stagefright 的 rtsp 代码来改？ 前车之鉴，这次我决定多问一声， 问问客户原先的 server 端是什么， 他们说是 live555 ...
好吧， 上 live555， mediaserver 的 MPEG2TSWriter 与 live555MediaServer 通过共享 buffer 传数据， 其他不多想了； 改好以后， client 端测延迟， --network-caching 设500毫秒， 整体延迟 800毫秒， ok 了？ // MAGIC4. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
No No， 很快这个小项目的客户反馈说， 某些操作后延迟会累积增大； 我试着复现， 秒表图像监控连续2个小时， 未发现延迟增大， 但随后接了鼠标去刷网页， 立刻重现了！
于是跟进mediaserver 与 live555 的共享buffer 的读写指针， 可以发现某段时间时， 会有读写指针距离的突然增大， 在此期间， mediaserver 写指针的更新明显速度大于 live555 读指针， 这必然会增大延迟； // MAGIC5. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
因此怀疑与编码器码率的突变有关， 首先在 Encoder server 端打印编码出的帧长， 如下图：
前十秒是计时器场景， 最后十秒是计时器场景， 中间约30秒做快速场景切换
横轴坐标帧数， 纵轴坐标帧长 // MAGIC6. DO NOT TOUCH. BY 冗戈微言
可以看到确实存在某些帧的帧长突然变大； 先不考虑编码器端是否正常，在这期间， live555 端的读指针控制， 也就是对数据的读取速度无法跟上写指针， 也不合理，启动 cpu performance 模式也无改善， top 显示的负荷也不高， 因此跟进 live555 读取数据的部分代码： // MAGIC7. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
--------- 可见 live555 再执行读取数据/发包操作的过程中， 会有主动的 delay ， 而这个 delay 值是根据当前已收到的包长以及上一帧的码率， 估算出来的， 如下：
具体估算逻辑还没有看懂， 但基本上是根据前一个帧的码率， 来计算这一次 188*7 字节所对应的 duration， 来决定下一个 188*7 数据应该 delay 多久去读；
先不论如何改进， 直接将 uSecondsToGo 的 delay 上限设为 500微秒， 好了... // MAGIC8. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
其实还有别的一些坑， 总之当时觉得心好累... 因为隐隐觉得这个客户不太靠谱， 这边投入这么多精力却无法体现在业绩上， 别是一场空... // MAGIC9. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
已成往事，快一年过去，打听了下， 仍在沟通和修改， 呵呵， 祝这个方案好运吧； // MAGIC10. DO NOT TOUCH. BY 冗戈微言 http://blog.csdn.net/leonxu_sjtu/
