RTSP的开源代码很多,移植方法也很多,所以在这里不做过多的描述。我主要来为大家讲述下移植过程中遇到的一些容易忽视的问题。
一、系统32位和64位兼容的问题目前大部分的嵌入式系统都是32位的,不过不乏有些64位的。所以在移植过程中我们要特别小心。下面是64位和32位系统数据类型所占字节的大小。
32位:
int 4个字节
long int 4个字节
long long 8个字节
指针 4个字节
64位:
int 4个字节
long int 8个字节
long long 8个字节
指针 8个字节
在移植过程中,我们会有网络字节序的转换步骤。因为比如包、ssrc和时间戳,都需要字节转换,这里要特别注意。在调试中,我们可以打印出转换前后的值,分析对错。当然,也可以通过wareshark抓包分析,查看相关信息是否正确。
二、打时间戳问题1、H.264时间戳:
timestamp=90000/帧率.*(帧号 - 基准帧号) //基准帧号,我们一般是找到关键帧的前一帧做为基准帧
2、AAC时间戳:
AAC比较特殊,因为它的编码需要1024的采样点才能正常编码(PCM-->AAC),所以我们一般以1024做为时间戳单位。
timestamp=1024*(帧号-基准帧号) //我们同样以找到视频关键帧为基准,记录音频此前的帧号做为音频基准
一帧音频数据也就是PCM音频源数据的1024采样点编码后的一包数据。
三、音视频无法正常播放的调试1、一般先调试视频,视频调试OK后,再加入音频调试
首先确定音视频源是否OK;其次确定RTP打包是否OK(此时要注意系统位数);网络抓包查看链接是否建立成功,SDP信息是否合理。
2、如果播放单视频,视频出现播放速率不对,过慢、卡顿或者过快,很有可能是时间戳有问题
具体查看时间戳数值是否整齐,还有就是抓包看包序是否连续,是否有丢包。
3、如果加入音频后导致音视频出现异常。则可能是以下两种原因导致
原因一:
音视频时间戳打的有问题。
原因二:
在发送视频帧的时候,中间插入了音频帧,导致解码端无法正常解码。(我其实不太赞成此推论,我怀疑是RTSP服务器版本的问题。因为理论上音视频的传输是通过不同的端口进行的。但是实际调试中,却是出现了该问题,抓包发现视频帧只要被插队,音视频播放就会出现异常)
因为视频帧很大,一般需要分多个包发送。比如一个I帧,它有300个包,而在发送到200个包的时候,突然被一个音频帧插队,后续在继续发剩下的100帧,这样接收端就没法解析播放。
解决方案:一采用单线程处理音视频发送;二采用多线程分别发送音视频时,应该加入锁,防止视频帧被插队。
这时个人的一些心得体会,欢迎大家一起讨论,一起分析,一起提高。