了解低延迟流媒体的技术

了解有关低延迟流的更多信息 流媒体东部2023.

罗伯特•莱因哈特: 我们拥有的技术, 当涉及到低延迟时，包括摄取协议, 或者muxers——它们不一定是同义词, 但WebRTC更像是一个传输层. It's not necessarily a specific way to mux audio and video, although, like HLS它是一个将音频和视频混合在一起的包装器. 但是当涉及到服务器摄取时，我们有低延迟协议. 抗利尿, 当然, had a huge boost during COVID because a lot of production workflows went to full 抗利尿--people using 抗利尿 within their own private LANs on the cloud, 使用抗利尿, 当然, 在位置, 或者从Teams或Zoom出来. 抗利尿是一种非常流行的——免许可, for the most part--ultra-low-latency way to get video around that can be uncompressed or compressed, 这取决于你使用的是什么口味的抗利尿.

RTSP/UDP, that's used more with the kind of security cameras, traffic cams out there. 同样，我们有各种各样的观众. 我并不是假设你们都来自媒体和娱乐行业. 所以说到市政直播, 我在不列颠哥伦比亚省的各个市政府工作, and across the United States I've worked with city of Colorado Springs, 加州的一些城市, 专门处理他们的交通摄像头. 他们也想要低延迟. 大多数摄像头都是IP摄像头 轴 或者其他像轴这样的供应商, and those are all RTSP pulls from those cameras into an infrastructure that hopefully won't add much more latency on top of it. 当然, RTMP Flash已经存在很长时间了，现在已经消失了, but RTMP is its legacy that even Facebook and YouTube today still use for ingest.

所以如果你在这些平台上做直播, 您可能已经知道延迟非常高, 因为我们不能再执行RTMP了. 我们可以用RTMP. 逐渐, 这将被逐步淘汰, 而是因为在RTMP之上有这样的基础设施投资, 我不认为它会在明年或后年消失. RTMP is probably gonna be a legacy protocol that sticks around and it can actually be pretty low latency--even ultra-low latency, 我马上会回到刚才跳过的那张幻灯片 Wowza that basically refers to tuning all of these different protocols and muxers that might be out there.

对于服务器摄取，我把流行的放在左边. 它缺少SRT，而SRT应该在那里. 当然，SRT是由 Haivision. 它是开源的, SRT正迅速成为RTMP的流行替代品, 特别是如果你使用的不是H的编解码器.264. 如果你想开始使用现代编解码器，比如 HEVC 或者AV1，你就不能很容易地使用RTMP. 尤里·乌多维琴科 Softvelum 已经改编了一个RTMP变体，将与其他编解码器一起工作, but that's very specific to the infrastructure that his company's been working on.

当然是客户交付, 我们是如何消费这些流的, not just how a server might be talking to a point of origin or a remote location for client delivery. 我们已经使用HLS-实现了标准的HTTP传输破折号 以及它的CMAF变体. 当然，WebRTC也是为客户端提供服务的.

我们仍然有web套接字服务. nanocosmos, 谁的口号是“一秒钟环游世界”,使用web套接字的回放机制. 所以对他们来说，网络套接字不一定是端到端的传输. 这是一种比WebRTC更容易扩展的客户端交付方式. 你仍然会看到一些web套接字实现. Web sockets have been around in browsers for a long, long time, and it's just a generic socket. You could send whatever you want over a web socket: data, audio, video. 这不是一个简单的协议，因为, 再一次。, it was not necessarily designed for sending video and audio and video around the web 像WebRTC was.

苹果HLS的延迟时间约为30秒. 通常他们会把它放在18秒以上的延迟栏里. 你的平均HLS延迟是30秒, mainly because people are using ten-second chunk sizes and a three-chunk playlist. So you multiply 3 chunks times 10--not including any kind of delays between those chunks being delivered across CDNs--and you're looking at 30 seconds. 将延迟减少到6秒并不难. 你会在HLS下看到, Wowza put it just after five seconds and you could get a two-second chunk size and keyframe interval times three. 再一次。, 如果你开始最小化你的块大小, just multiply it by the number of chunks that are listed in the manifest, 这就是你的平均延迟. 你还需要花些时间, 仅仅是因为边和原点之间的传输. But I would say if you have a two-second segment size and it's on a playlist that's repeated three times, then you're probably looking anywhere from 6-10 seconds of latency in a tuned playlists like that.

这并不难做到. Anyone who's got a media server can tune their packaging to that and not have to go through many jumps in not too many hoops to do that. 当我们接近这个低于一秒的延迟时, 我们开始接触更多不同的技术，比如WebRTC, 你首先可以看到的是，这几乎是实时的. 我们接近250毫秒. 一般来说, 我想大多数人都希望达到500毫秒以下, 如果不低于300毫秒的延迟，当他们使用WebRTC. 当然，这是有代价的. WebRTC doesn't scale as easily as any of these http methods of delivery, 所以你得做相应的预算, whether it's building out your own WebRTC infrastructure using someone else's.

现在我们有 低延迟HLS (LL-HLS) 这本书已经出版好几年了. 我记得当罗杰·潘托斯来到2019年的流媒体西部. He was talking about 低延迟HLS for the very first time at the conference. 所以我们有一段时间来观察新冠病毒的发展情况. The original 低延迟HLS spec had some HTTP version 2-specific PUT commands in it, 他们已经删除了它，这样cdn就不用使用它了. And instead they're using this preload hint that you can put into manifests that are specifically 低延迟HLS. 当然，您也可以调优其他任何一种，比如RTMP.

在那些日子里 总部琐事 是一款非常受欢迎的益智游戏吗, 我有几个客户也想加入这个行列, and we were using RTMP libraries in native apps to play RTMP in a smartphone app. 所以如果你想建立自己的定制回放技术, then you have a lot more options still if it's not gonna be strictly within the domain of the browser. So RTMP could be an option for playback if you were building a custom environment for it these days.

I wouldn't put too much weight into RTMP playback just because we've got options that are a lot more mature now, 像WebRTC. 就在几年前, WebRTC didn't have the kind of cross-platform and cross-browser acceptance or standards that we have now. 现在你不用太担心H了.264 vs. VP8. Those are still codecs that are in play that might need some transcoding back and forth, 取决于您的工作流程. 但这已经走了很长一段路，COVID再次加速了这一进程.