低延迟编解码器在多大程度上减少了延迟?

观看流媒体东部连接的完整面板，延迟仍然很糟糕(以及你能做些什么) on the 流媒体YouTube频道.

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

阅读这段录音的完整文本:

Casey Charvet: 人们理解了一种方法. 我不会说有一个标准，没有什么是有效的. 从学术上讲，我认为这种方法可能会被证明是正确的. 但就目前而言, 如果一个客户来找我说, "Hey, 我有一份工作，下周就要开始了，我得在10点前交货,000 people,“我不会推荐任何东西，除了像HLS这样经过验证的东西. 如果他们想要低延迟，我们可以把片段缩短到两秒. 但是随着这些低延迟的修订出现在现有的协议中, 他们一直在发送一个恒定的字节流, 因为苹果的LL-HLS——基本上, it's like, "Okay, 这是一个200毫秒的片段，这是另一个200毫秒的片段.“视频有多少毫秒，或者1500字节的数据包? 我们离回到单播流媒体越来越近了, 在我们牺牲了RTMP和所有这些之后.

Rob Roskin: 从交付方面来看，我们还没有看到低延迟HLS-DASH的大量使用. 坦率地说，我不认为低延迟HLS已经准备好了，但即使是DASH或CMAF ... CMAF本质上在低延迟时稍好一些，原因我们现在不讨论. 但如果你想亲手打破电视的10秒延迟, 我们仍然在数百万用户中使用专有协议. 如果你有10000个用户，就像我们一直说的，有很多方法可以做到. 如果你是Disney+，你将回到基于http的协议. 我认为我们真正需要摆脱的是, 不管我们是否传输文件或者我们如何在比特流或文件中移动这些数据, 这是TCP的握手吗, I received videos files.“大多数时候，告诉我已经太晚了. 所以如果你没有得到它们, 只要等到你拿到下一个，然后把它扔在地板上，直到你准备好离开, 哪一种是UDP风格的技术. 我认为，为了达到这种规模的延迟, 我们不能再使用TCP了.