Encoding Best Practices to Reduce Latency
从流媒体东连接观看完整的面板, Latency Still Sucks (and What You Can Do About It) on the Streaming Media YouTube channel.
Learn more about low-latency streaming at Streaming Media West 2020.
Read the complete transcript of this clip:
Jason Thibeault: If we assume that latency is from glass to glass, 我们知道，从获取内容到观看者消费内容这一过程中存在许多组件. There's encoding. There's a virtualized container, 把视频从一个比特率转换成另一个比特率的东西, one format or one package to another. 有数字版权管理，有隐藏式字幕，中间还有各种各样的东西.
Let's talk about encoding a little bit. 我知道有很多编码供应商都在大力推动上下文感知编码——而不是将一个配置文件应用于视频的每一帧, but applying multiple profiles to the frames, depending upon what's happening in the frame. 所以，如果你有一个会说话的脑袋，那和一个在球场上踢球的人是不同的, 在编码过程中可以做哪些选择来改善延迟? 如果那个编码器在把视频从玻璃杯传送到玻璃杯时造成了一些延迟怎么办? 比如说，关于块大小有哪些最佳实践? 关于概要文件变量有哪些最佳实践?
Casey Charvet: 假设你的相机增加了一两帧延迟, and your video switcher adds two frames of latency. 在我们的编码器上，我们使用了一些速率控制技术，它向前看四帧. 所以它在编码器中有一个四帧的缓冲区. 接收SDI信号的采集卡有缓冲器.
所以在我们开始处理视频帧之前, we're already six frames in, 在每秒30帧的情况下，这大约是五分之一秒. 所以很容易发现在字节离开起始站点之前就有一秒或半秒的延迟.
我们所做的一些事情是我们可以决定我们不太关心利率控制. So we're just going to throw that out the window. 我们要关闭这个四帧，前视缓冲. 如果我们想要低延迟，我们不太关心每字节的质量效率. 所以我们愿意花更多的字节来降低延迟. And so we might have shorter keyframe intervals. So we're sending out more I-Frames. If you want the lowest latency possible, 你只是把一些东西放进了一个近乎实时的编码器, MPEG-TS and I-Frame-only and throw it somewhere. 你会有35毫秒的延迟，这很棒, 但当我们试图提供受限带宽或大规模交付时，这就行不通了.
我认为肯定有办法在初始端调整你的编码配置文件以获得更低的延迟. 如果你从那里开始，一直到你的生产管道, your net latency at the end is low. 如果你一开始就有很多延迟, you're going to be fighting that the whole time.
Marc Cymontowski: 区分故事的两个方面是很重要的——摄取方面和传递方面. On the ingest, you often have low-latency protocols, because, as Casey mentioned, if you have an MPEG-TS encoder, and it's a hardware appliance like our encoders us, for example, you can achieve very low latency. 你可以把它包装在传输流中，或者你可以通过本地网络发送它，你不会有任何问题. 但一旦你通过公共互联网到达云端——无论是进行转码和重新包装，然后传送视频，还是端到端直接分发视频——这就变成了一个复杂的部分，因为你通常无法获得你希望在本地拥有的网络质量. 因此，将内容放到云端是第一个挑战.
In many cases in the past, RTMP has been used to do this, 基于TCP的协议有很多限制因为拥塞控制和一些线路阻塞问题不能给你完全的吞吐量. 基于udp的协议(如SRT)可以更好地利用可用带宽, 但是你必须对途中发生的数据包丢失进行恢复. 但当你进入云计算领域，你想向很多人提供服务, many, 对于很多人来说，像MPEG-TS这样的流不是很可扩展，因为你需要传递整个数据, live linear to every single person. 这就是HLS繁荣的开始因为你突然重新打包数据和TS, it's pretty easy. 你只需要把TS分割成块然后你就可以把它做成HLS流. 当你把它分成块，把数据分成段的时候, 您可以更好地扩展，因为您可以使用缓存机制跨服务器分发文件，然后再交付. 这就是在传送端，延迟被引入的地方.
Related Articles
GigCasters' Casey Charvet, Haivision's Marc Symontowski, 流媒体视频联盟(Streaming Video Alliance)的杰森·蒂博(Jason Thibeault)也在考虑缓存, latency, and content delivery in a post-chunked media world.
17 Aug 2020
GigCasters的Casey Charvet和CenturyLink的Rob Roskin讨论了新的低延迟版本对现有协议的有效性，以减少流媒体东2020的流媒体延迟.
14 Aug 2020
Companies and Suppliers Mentioned