网络视频传输技术解析：直播和视频通话背后的协议之争
现在看直播、打视频电话已经是日常了，但视频是怎么通过网络传过来的，很多人并不清楚。其实不同场景用的传输协议完全不一样，直播和视频通话走的就不是一条路，各有各的取舍。
先说直播。直播的特点是单向的，主播推流，观众拉流，对延迟的要求没那么高，几秒甚至十几秒的延迟都能接受。直播最常用的协议是RTMP和HLS。RTMP是Adobe搞的，基于TCP，把视频流切成一个个消息传输，延迟一般在3秒左右，适合推流端到服务器。HLS是苹果搞的，把视频切成一个个小的ts文件，通过HTTP分发，观众用播放器按顺序下载播放，兼容性好，基本上所有设备都支持，但延迟比较大，通常在10秒以上。
再说视频通话。视频通话是双向的，对延迟要求极高，超过400毫秒就感觉说话有延迟，体验很差。视频通话最常用的是WebRTC，这是谷歌开源的实时通信技术，基于UDP，不用建立连接就发包，延迟可以控制在200毫秒以内。WebRTC还内置了回声消除、噪声抑制、自动增益这些音频处理，以及拥塞控制、丢包重传这些网络优化，用起来很方便。
为什么直播用TCP而视频通话用UDP？TCP的特点是可靠，丢包会重传，顺序保证，但重传会带来延迟。直播对延迟不敏感，用TCP保证画面不花屏、不卡顿更重要。UDP不保证可靠，丢了就丢了，但延迟低。视频通话宁可丢几帧画面也不能等重传，不然说话就断断续续的，所以用UDP更合适。
视频传输还有个关键技术是码率自适应。网络带宽是波动的，WiFi有时快有时慢，4G信号时好时坏。如果码率固定，带宽不够的时候就会卡，带宽够的时候又浪费。码率自适应就是根据网络情况动态调整编码码率，网络好就调高码率画面更清晰，网络差就调低码率保证流畅。WebRTC里的GCC算法就是干这个的。
国内的直播平台近几年在搞低延迟直播，把延迟从几秒降到1秒以内，用的是基于UDP的私有协议，类似WebRTC的思路。以后直播和视频通话的技术边界会越来越模糊，低延迟、高可靠、自适应会成为共同的追求。
下一篇：没有了