「腾讯」一文读懂腾讯会议在复杂网络下如何保证高清音频( 六 )
本文插图
刚才讲的网络延时估计与跟踪 , 相当于它在对网络包进行合理缓存 , 保证数据的完整性 。 那么怎么样把已经收到的数据包延时压下来 , 或者让数据包水位不够的时候 , 把这个时间轴拉长?其实这里面也是一个 Waveform Similarty 的算法 , 我们叫 Wsola , 它兼顾 PCM 数据在幅度上 , 频率上、以及相位上的延续性算法 , 效果还是不错的 。 这个算法是一种基于拓展压缩语音长度 , 是一个变长不变调的技术 , 它是基于 Pitch 基音周期进行相似波形叠加的一个算法 。
音频编解码器的抗丢包能力 Codec 编解码器专题一般会去讲解码器的历史或音质对比 , 我们今天从网络抗性的角度重点是看它的带内抗丢包能力 , 或者 Codec 层面能够给抗丢包带来一些什么收益 。
本文插图
Codec 层面不能指望完全无损的把二进制包恢复 , 那它的优势就哪里?
它的优势在于可以节省包头 , 不管是以前的私有协议还是现在的 RTP 协议 , 用于传输的 IP , UDP 协议字段是节省不了的 , 信道编码的方法比如带外 FEC , 或者重传 ARQ 都是对完整数据包进行恢复或者请求重传 , 这里面的数据包头占用了许多流量 。 而所以在 Codec 中的带内 FEC 里面的实现算法里面 , 一般来说它可以携带 t-1 帧的数据 , 而这个 t-1 帧的数据包可以用一个低码率的参数进行编码 , 在接收端收到这个携带 t-1 帧的数据包 , 则可以解码重建出来 t-1 这一帧质量稍逊一点的数据 。
讲到这里就是大家也有个疑问 , 比如说 silk 也是 t-1 , 然后它的抗丢包特性大概 15% , 而最最新版本的 Opus1.3.1 大家可以听一下不同丢包率场景下他的表现 , Opus 在内它为什么最后 30% 呢?
本文插图
这个图就是刚才说的全家桶算法里面使用的抗丢包算法基本都包括在里面了 , 我们所使用的一些方法在这个合集里面只是占其中一小部分 。 PLC 就是 Packet Loss Concealment , 丢包恢复算法它的内涵还是比较丰富的 。 画一个树状图 , 把整个合集集中起来发现它有两大阵营 , 一个是基于发端的 , 一个是基于收端的 。 基于发端的有被动式和主动式 , 重传类的就是主动式 , 前向纠错的就是被动式 。
至于重传为什么给它送到发端?以我的理解 , 在接收端不管是 Ack, Go-N Ack 或者是 NACK 方式 , 都是接收端的反馈 , 真正要发包还是在发送端的 , 所以还是基于发端 。
基于发端的另外一个大类就是 FEC 。 前面讲的 FEC 工程实践和原理就是所里德—罗门算法 , 这种算法还有很多类似的 , 比如喷泉码 , 比如 RLNC 。 这个 RLNC 有个比较好的特性 , 可以支持重建码 , 比如在网络比较好的情况下 , 我现在收听上百人千人 , 针对不同的下行用户 , 再根据下行信道的参数进行重新编码 , 不至于像用喷泉、RS 或异或只能保持原状 。 另外 , 其中信源相关的 FEC 就是上一页讲的 Codec 层面的带内 FEC 。
基于接收端有很多方法 , 比如插入式方法 , 比如在接收端 , 那么插入静音、白噪音 , 或者干脆把前面一个包复制一下 , 就不管它的相关性和衔接 , 这样效果不太好 。 而且它的补偿效果也就是 20 毫秒顶天了 , 在衔接不好的情况下还容易产生金属音 。
另外一大类就是内插式的方法 , 比如波形相似法 , 还有基音周期复制法 , 还有就是波形伸缩法 。 到这块 , 所有的方法就能很好地解决幅度连续、频率连续、相位连续的特征 , 所以它的效果总体来说还是不错的 。
另外基于接收端的 , 它有一类再生补偿方法 。 比如时域数据传输本身挺大的 , 如果在变换域的话 , 它可能只需要一些变换域的参数 , 在接收端进行恢复 。
推荐阅读
- #程序员#腾讯女程序员相亲遭对方嫌弃,晒出聊天记录感叹:太难了
- 『腾讯科技』淘宝天猫蒋凡在阿里内网回应传闻:深表歉意,恳请公司展开调查
- 「链得得APP」一文彻底读懂BTC的“祖孙三代”
- 「腾讯」腾讯视频盈利难:2019年亏损30亿 盗墓题材连拍五年没水花
- 服务@云市场跨步式发展 打造ToB云市场阿里腾讯外“第三股势力”
- 每日经济新闻咨询@联邦学习成人工智能新贵 腾讯安全:技术服务能力才是重点
- 腾讯科技■消费券“暖”市场,中山市发2000万微信消费券
- 「腾讯创业」当年上《职来职往》《非你莫属》的“明星”公司,大多已经不见了
- 游戏■腾讯代理全新手游来了:MOBA+吃鸡 6月9号上线
- #3D打印#一文带你了解3D打印如何制作家具
