多功能多媒体播放器说明书（多媒体那些事-播放器漫谈）

在昨天分享的文章《多媒体那些事-播放器漫谈（一）》中，我们详细讨论了HTML5、Flash、iOS、Android四个平台的音视频播放技术及常用方案，但它们之间到底有些什么差别？我们应如何选择合适自己的方案？

先对比一下播放方面的技术差异：

我们尝试把产品场景分为四种，以下是对各自的建议：

四、几个常见问题

做一个播放器远没有想象的那么简单，来看一下播放器的几个常见问题。

1、怎么做音视频同步？

对于系统封装好的播放器，则无须关心这个问题，但如果要实现一个完全可控的播放器，从数据接收->解复用->解码->音视频同步->渲染都需要去干预。处理音视频同步的原因已在前面章节讲过了，这里着重讲实现原理。

做音视频同步之前，先补充个知识点，DTS与PTS（I帧、P帧、B帧请自行补充）。

这个时间戳的意义在于告诉播放器该在什么时候解码这一帧的数据。

这个时间戳用来告诉播放器该在什么时候显示这一帧的数据。

视频编码中必存在I帧，可能存在B帧、P帧，B帧是双向参考帧，因此会打乱帧的解码和显示顺序，因此引入了DTS和PTS来应对这种情况。普遍情况下B帧压缩率较I帧、P帧高，在点播视频中比较常见，直播视频中一般没有B帧，在此情况下，DTS和PTS应该相同。音频编码因为没有参考帧的概念，是不需要DTS的。

（图：I、P、B、DTS、PTS关系）

在清楚了DTS和PTS之后，可见PTS对音视频同步起关键作用，音视频常见的同步方式有三种，分别是：以音频为主线同步、以视频为主线同步和以外部时钟同步。第一种最为常见，也是比较符合人类视觉听觉感官的方式（音频变速会导致变声），同时音频的播放速率比较固定，比较容易作为主线管理，其同步过程总结如下：

❶ 解码器从输入的数据封装中解出音频PTS、视频PTS；

❷ 创建音频播放线程，音频按固有的采样频率播放；

❸ 创建视频刷新线程，按一定频率（10ms）定时检测；

❹ 通过音频、视频的时间基（time_base）换算成相同时间基准的PTS；

❺ 在视频刷新线程中计算当前真实的音频PTS、视频PTS：

计算currentRealVideoPTS - currentRealAudioPTS的差值diff；

❶ 若diff <= 0，说明视频显示慢了，这时需要马上显示该帧数据；

❷ 若diff > 0，则视频酌情做适当的延时显示；

一帧数据的音视频同步检测就此结束。

以上方法的核心理念是通过延时评估算法来控制视频帧慢放或快放，以此做音视频在合理范围内保持同步。

2、怎么做到视频秒开？

有以下几点可以优化：

❶ 服务器端下发关键帧数据，保证播放器第一时间解码到有用的数据；

❷ 播放器可以在选择音视频解码器环节做优化，通过外部预设解码器相关参数来减少解码器类型探测耗时；

❸ 在业务层面上优化，使用HTTP-DNS服务做到精准调度，选择最优服务器获取播放数据；

❹ 提升音视频服务节点质量；

3、怎么做到低延时？

延时这词是针对直播而言，先看直播系统的架构图：

（图：UCloud直播系统架构图）

从图中可以看出，可能产生延时的环节有：

❶ 主播端推流至上传节点的延时；

可以通过接入HTTP-DNS为主播选择最优节点，减少传输延时。

❷ 主播端发包的延时；

主播端应尽快发送本地数据至上传节点，对于弱网环境，应该有合理的控制策略，尽量避免大量过期数据阻塞在本地。

❸ 上传节点到服务器集群的数据分发、转封装、转码等耗时；

分发的层级越多，延时则越大，这块也主要依赖于服务器间的网络状况。

❹ 观众端到下载节点的延时；

可以通过接入HTTP-DNS为观众选择最优节点，减少传输延时。

❺ 播放器本地存在buffer；

常规的播放器都会有本地缓存，合理的缓存设置可以为用户带来较好的观看体验，减少视频的卡顿次数。如果对延时有较高要求，可以减少buffer的缓冲时长，甚至可以把buffer去掉。

4、播放器卡顿的原因有哪些？

再看上图，卡顿可能的原因有：

❶ 主播端推流与上传节点传输不顺畅；

❷ 服务器间传输出了问题；

❸ 观众与下载节点传输不顺畅。

五、总结

看完这些，相信大家对基础的播放流程及各平台上音视频处理技术已有初步了解，但是要做好多个平台的播放器并非易事，要做大量兼容性适配、容灾、性能调优、播放质量统计反馈、新功能迭代等工作。因此，一款好的播放器需要不断打磨，UCloud也将持续投入更多资源去支持该领域的运作。

点击“阅读原文”，了解更多UCloud多媒体技术，获取更多业务支持。

,