降低H.264流播放时延的几种方法

野性酷女 2022-07-18 04:10 533阅读 0赞

2008-09-21 22:29 3246人阅读

在交互性强的网络视频聊天或视频会议中，视频播放时延是关键的系统性能质量指标。如果播放延迟偏大，那么会严重影响用户的交流观感。

视频系统的播放时延一般来源于四个方面：发送端的采集和压缩编码时延；服务端的缓存转发时延；网络传输时延；接收端的解码和播放时延。经测算，在局域网环境下，前三个方面的时延是一个比较小的固定值：发送端的时延有1-2帧的延迟，采用的Adobe FMS的服务端平均延迟约两帧，100M局域网的网络传输时延相对可以忽略不计。在发送端欠理想的状况下，接收端所造成的时延是系统的主要时延。控制好接收端时延是一件看似容易、实则相当棘手的事情，采用常规的技术解决方案可能难以满足应用要求。

在DirecShow应用模式下，降低接收端时延的最简单方法是：将filterGraph的系统时钟设置为空，或者source filter向下游发送的sample时戳设置为零。这样，接收端就会对收到的H.264流“尽力而为”，不加任何阻塞地解码和显示。虽然这是时延最小的处理方法，但是当发送源本身不均匀发送（发送端编码延时不均匀、服务器多帧缓存转发、点播模式等的影响），就会导致出现播放“时卡时顿”的现象。因此，应采用设置sample时戳的方式，在显示端相对于发送源的采集时间进行显示，才能忠实流畅地播放。由于必须对source filter的sample打时戳，decoder和render的行为机制就复杂多了，处理得不好会导致比“尽力而为”大得多的延时。

根据本人的实践经验，对于H.264流，可采取以下几种措施来改善：

1. 避免采用demux filter

在微软所推荐的directShow解码播放模式中，filter graph采用的是source->demux->decoder->render。demux用于A/V分离和解析适配，使下游的decoder能够处理。demux分为拉模式和推模式两种，支持拉模式demux的source filter开发简单，但处理延时比较大；推模式demux需要使用到一些内部接口，我们为了使用elecard push demux，专门购买了一套Elecard SDK G4。虽然时延显著减小，但比较遗憾的是，push demux在处理1080P的H.264流时不够稳定。

H.264裸流本身就包含了NAL层信息，H.264/AVC decoder是直接可以进行解码的。因此，在无需对数据进行A/V分离的应用环境下，降低延迟的最佳方法是采用source->decoder->render。这不但省去了demux所带来的延迟，而且简化了架构，资源消耗小，稳定性好。

2. 屏蔽质量控制消息

大多数的H.264/AVC decoder缺省选项是支持Quality Message处理的，在发送源欠理想的情况下，Video Render会向上游发送Quality Message，可能会引起decoder主动阻塞，产生不必要的延迟。

可采用以下方法消除这种延迟：

（1）修改decoder属性框中的质量控制选项，使其不对质量控制消息进行反馈处理。可以进入属性页手工设置，或者设法获得属性接口支持，通过程序修改。

（2）在decoder和Video Render中插入一个Translate-In-Place filter，重载其中的Notify，使decoder收不到Quality Message。

3. 降低decoder的启动时延

Filter Graph在Video Render收到首帧sample后，就建立起与发送端一致的显示时间轴，在后续的播放中始终保持与发送端时间轴相对基准不变。因此，首帧sample的延迟将会以常数的形式迭加到后续帧的sample延迟中，decoder处理第一个sample的处理时延（启动时延）越小，那么流播放的时延就随之减小。

如果decoder处理首帧的时延与平均解码时延相差不大，那么这个时延完全可以忽略不计。然而，对于H.264/AVC decoder来说，这个初始时延远大于平均解码时延。造成这种原因有两个因素：I帧的搜索定位；decoder的初始化。

可采用以下方法降低这种延迟：

（1）source filter在初次运行中，跳过所有非I帧，直到I帧来了，才开始向decoder发送，从而消除decoder搜索I帧前的缓存；

（2）发送端预先发送一段明显低于正常图像质量的视频流，使decoder可以更早、更快地完成首帧的处理。虽然模拟试验中，效果不错，但是这种方法需要发送端配合，存在一定局限。具体做法在国外的相关专利上有详细介绍。

在没有采用以上方法前，接收端在每秒30帧时的H.264播放时延高达2秒，10帧的就更高啦。采用除3.2外的所有方法后，接收端在每秒10帧的H.264播放时延降到了0.4秒，总系统时延小于0.8秒；每秒30帧的播放时延降到了0.2秒，总系统时延小于0.5秒。