标签：同步 logs 解码 采样 timestamp 用户 前端 处理 完全
在现今如火如荼的直播热潮中，最新的技术趋势是多用户之间进行连麦交互。连麦技术需要处理很多问题，包括音视频的解码及重新编码，音频重采样，视频帧率重采样，音视频同步等。其中的音视频同步包括合并后的流中的音视频时间同步，也包括多个连麦用户之间流的时间同步问题。这里讨论多个连麦用户之间的流时间同步问题。
这里提出一种方案，算是抛砖引玉，拿出来仅供大家讨论，欢迎指正。
方案说起来很简单，就一句话：各连麦用户使用同一时间参考系。为了实现该目标，需要以下几个步骤保证：
1. 各连麦用户开始推流前，到同一时间同步服务器获取到当前时间戳，作为相互之间同步的基础。比如主播用户推流时获取到时间戳1492764087700ms，作为以后整个房间各条流的时间同步基准。
2. 主播推流时，记录从时间同步服务器获取到的时间戳。如map["stream1"] = "start_timestamp"。后续连麦用户加入房间"stream1"时，获取到该房间的起始时间戳（主播的起始推流时间），然后用从时间同步服务器获取到的当前时间戳减去房间的起始时间戳，即是当前用户推流的起始时间偏移。比如主播时间戳为1492764087700ms，次播/副播1在1492764187700ms开始连麦，即相对主播推流的时间晚了100s。如果主播时间戳从0开始，那么次播/副播1的起始时间戳就是100s。以此类推，后续次播/副播2的起始时间戳可能是200s，246s等等。技术上完全等同于单条流中的音视频流相互同步（参考音视频重新编码时间戳同步问题）。
技术点总结：
1. 一台rtp时间同步服务器。
2. 连麦消息服务器，用于连麦用户之间的时间同步消息等各种消息服务。
3. 连麦前端sdk需要在自己推流前到连麦服务器获取自己开始推流的起始时间戳。如主播，起始时间戳可为0（对应rtp服务器绝对时间为s）, 其他后续连麦用户的起始时间为t-s（t为当前rtp服务器绝对时间）。
标签：同步 logs 解码 采样 timestamp 用户 前端 处理 完全
原文地址：http://www.cnblogs.com/NerdWill/p/6785883.html
