解决SRT稳定推流到SRS———网络丢包部分

昨天说到AAC音频编码整理完代码后并没有解决问题，说“整理”是确认了一遍编码参数设置，以及等待一帧音频帧数据的代码逻辑。

于是转到SRS服务器上，在serve error code=5011的前后增加了许多日志，此处出错日志是音频重采样地方，即从SRT收包后，转RTMP和WEBRTC时根据后项音频标准进行重新编码。

发现音、视频流的PID会在没有结束完整一帧音频或视频时，收到另一个流的PID，这个代码漏洞让我兴奋不已。在着手解决该问题前，还需确认是否网络丢包导致的？

于是乎，在嵌入式设备端又增加大量日志，重点是要把每包MPEGTS时间戳记录下来，比对两端日志，发现嵌入式设备音视频采集后到SRS服务器的网络延时有400+毫秒左右，实话说有点小兴奋，不是因为时间的多少，而是从此可以客观地分析网络延时大小了。

一通操作后事与愿违，并没有发生网络丢包，这里会有人问网络丢包发生在网络链路中不可以吗？能确认这个问题是否发生，这不是还有SRT吗？它告诉我没发生，我就信了。

网络没丢包而且SRS都收到了MPEGTS切片包，到这里貌似没有更好的办法继续排查问题了。冥思苦想中