Asterisk播放mp4（6）——音视频同步

Asterisk 现有版本不支持播放视频文件（支持视频通话），无法满足发送视频通知、视频 IVR 等场景。本系列文章，通过学习音视频的相关知识和工具，尝试实现一个通过 Asterisk 播放 mp4 视频文件的应用。

• Asterisk播放mp4（1）——音频和PCM编码
• Asterisk播放mp4（2）——音频封装
• Asterisk播放mp4（3）——搭建开发环境
• Asterisk播放mp4（4）——H264&AAC
• Asterisk播放mp4（5）——MP4文件解析
• Asterisk播放mp4（6）——音视频同步
• Asterisk播放mp4（7）——DTMF

SIP终端和Asterisk之间通过RTP协议传递媒体数据，视频流和音频流分别用不同的端口传递，这样就可能出现音视频数据不同步的情况。本篇完整学习RTP和RTCP协议中如何解决音视频流同步问题。

RTP时间戳

每个RTP包都包含中都包含时间戳（timestamp），它代表传送包的第一个字节的采样时间（和媒体帧的dts时间对应）。时间戳的单位由媒体流的时间基（timebase）决定，例如：h264的90000，pcma的8000等。时间戳代表的是帧和帧之间的相对时间，它的初始值是个随机数。如果几个包中的数据是在同一时间开始的，那么它们的时间戳可以相同，例如：一个视频帧分成几个包传递。不通媒体流之间的时间戳是独立的，没有相互关系。

通过上述信息我们可以看到，只通过RTP是无法解决音视频同步问题的。

mp4文件中的音视频同步

mp4文件中包含了音频流和视频流，而且没有哪个字段指定了视频流和音频流的相对开始时间，那么mp4文件的存储方式是否会影响音视频同步（假如mp4是先放所有的音频数据，再放所有的视频数据，而文件又特别大，显然会对同步产生很大的影响）？前面的文章研究过mp4的文件结构，stco中记录了每个媒体数据chunk在文件中的位置。这个存放位置和播放时间有关吗？通过ffmpeg生成mp4文件时，可以设置音频晚于视频生成，下面我们看分别设置延时1秒和延时2秒的情况。

ffmpeg -i testsrc2-baseline-31-10s.h264 -itsoffset 1 -i sine-8k-10s.mp3 -map 0:v:0 -map 1:a:0 testsrc2-baseline-31-10s-sine-9s.mp4

延迟1秒开始音频

ffmpeg -i testsrc2-baseline-31-10s.h264 -itsoffset 2 -i sine-8k-10s.mp3 -map 0:v:0 -map 1:a:0 testsrc2-baseline-31-10s-sine-8s.mp4

延迟2秒开始音频

通过数据可以看出，chunk在文件中的位置和媒体帧的开始播放时间存在关系，那么按顺序读取mp4中的每一帧，并按照dts时间发送，就基本能够保证音视频的同步。

用RTCP控制时间同步

虽然mp4文件自身的存储顺序一定程度上解决了音视频流同步问题，但是这不是一种严格控制的手段，RTP包通过网络发送仍然有可能导致产生不同步。和RTP配套的RTCP提供了一种解决媒体流时间同步的方法。RTCP通过发送SR（Sender Report）包，告知其包含的时间戳（RTP timestamp，32位）对应的时钟时间（NTP timestamp，64位），这样接收端就可以根据这个对应关系计算出每个RTP包的时间戳对应的时钟时间。如果每一路媒体流的时间戳都对应到了时钟时间上，那么不同媒体流中的帧的相对时间也就知道了。

RTCP包结构

ffmpeg在推送RTP流时，音频和视频流会首先各自发送RTCP SR包。

ffmpeg推送RTP音频流-RTCP

ffmpeg推送RTP视频流-RTCP

The recommended value for a fixed minimum interval is 5 seconds.

RTCP包在整个推流过程中应该按间隔发送，在RFC3550规范中推荐发送RTCP包的最小间隔为5秒，Asterisk和ffmpeg中都采用了这个时间间隔。但是，ffmpeg推送RTP流时会首先发送RTCP的SR包，Asterisk并不发，之后都是每5秒发一次。所以Asterisk本身并没有提供通过发送RTCP包进行音视频同步的机制。

终端（linphone）

如果RTP的时间戳和媒体帧的dts相对应，那么似乎终端只要接收到了所有的帧就应该能正常播放，和发送的速度应该无关。下面做个实验看看发送速度是否应该播放效果。

播放一个10s的视频，快速发送（获得媒体帧后立刻发送，所有帧都发送后，等待到视频正常播放结束时间再中断绘画），在rtp帧间不添加间隔，时间戳正常。红色5秒，绿色5秒，只能看到红色。红色2秒，绿色8秒，可以看到红色和绿色，但是红色播放不足两秒。说明linphone不是完全按照h264的dts和pts时间进行解码和播放。

快发红2秒绿4秒抓包

通过尝试发现linphone不支持通过RTCP进行音视频的同步。

终端（VLC）

ffmpeg可以通过output_ts_offset参数模拟音视频同步的场景。指定这个参数后，ffmpeg会将媒体帧的RTP包的时间戳加上这个偏移量。

ffmpeg -re -i sine-8k-testsrc2-gop10-10s.mp4 -c:a pcm_alaw -vn -output_ts_offset 3 -f rtp rtp://192.168.43.165:5006 -an -c:v copy -bsf: h264_mp4toannexb -f rtp rtp://192.168.43.165:5008

ffmpeg发送RTP音频延迟3秒

可以看到RTCP保证的RTP timestamp的值是765982054，第1个音频RTP包的timestamp的值是766006054，两者之间接收间隔0.000014秒，时间戳的差是24000，pcma的时间基是8000，换算后间隔为3秒。

通过vlc接收ffmpeg推送的RTP流，可以直观感受到视频播放的3秒时，开始有音频，视频已经结束音频仍然会延续3秒，说明vlc正确处理了RTCP的设置。

可以用同样的命令向注册到asterisk上的linphone发送媒体流，但是linphone并有将音频流延时3秒。