WebRTC部署基础

了解更多关于流媒体分析的信息流媒体的下一个事件.

从流媒体东部观看完整的演示， VES204. 在低延迟流媒体服务中部署WebRTC, in the 流媒体会议视频门户.

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

Dr. 亚历克斯Gouiallard: WebRTC中的编码器很慢, 其中一个原因是流媒体行业的大多数人, 像Netflix, 这个流是预先录制的内容, 会关注解码器的速度吗. 他们有世界上所有的时间来编码, 他们有多通道算法, 他们将使用机器学习, 每部编码, 以此类推. 他们之所以有所作为，是因为他们有很多时间进行编码. 但当你解码时，这是用户体验，所以它需要快.

以AV1为例, 例如，你有dav1d, 以及一些与AV1编解码器相关的项目，这些项目只有解码器, 因为这是他们唯一真正关心的事情, 这不是问题所在. 所以Netflix和YouTube提供了一些自编码的数据集，供人们尝试解码器, Firefox宣布, I think, 去年10月或11月, 在Firefox中支持AV1, but, of course, 他们的意思是支持解码，而不是在WebRTC. 好吧，你知道，很公平.

我们会讨论其他人提出的其他要求. Somewhere. 我们现在就开始吧，问题是什么? 如果你想决定什么是慢的，你需要知道什么是快的，对吧? 那么你最快能开到多少? 如果你看一下在单个计算机共享内存上GPU的不同编码速度, 你知道生活是美好的, 平均是每帧11毫秒. 这是4720便士，所以你可以在5到15便士之间，这是你能期望的最快速度.

那么AV1和libaom，以及类似的东西呢? 我们今天达到的速度是多少? 这是最新的消息, 我们是AOM的成员, 我们为每个人做基准. 这是AOM 1080p， 720和VGA，这是英特尔编码器. 这些只是编码速度, 你可以看到，就速度而言，自由贸易并没有取得很大进展, 就FPS而言, 但英特尔的AV1实际上是在做很多工作, 最近又没那么多了. 这是Netflix和英特尔关于实时编解码器的声明. 有趣的是, 这是对数标度, 这是每秒一帧, 这是每秒10帧, 然后是20, 30, 40, 50, 60.

所以，VGA，没有人真正关心流媒体，对吧，所以让我们认真一点. 720p. 你可以达到30 FPS, 今天是720p, 但那是在戴尔XPS上, you know, 你可以在好市多买到的普通东西, 根本不是什么特殊的硬件. 你已经可以达到30 FPS了, 但问题是, 最重要的问题是, 30 FPS是不是实时的? 不幸的是，这真的是误导, 奈飞和英特尔的新闻稿真的很误导人. 30fps为吞吐量, 这不是延迟, 所以你可以用英特尔编码器实现40+ FPS, 但是有6-7秒的延迟, 这就是今天的问题, 这不是一个实时编解码器.

他们是怎么做到的? Well, 这有点像带宽, 你可以有每秒1gb的连接, 但它通过卫星传输, 所以往返时间是1秒. 这里是一样的, 它们并行地对许多帧进行编码, 所以他们实现了40或60 FPS的全局吞吐量, 但是如果你计算延迟, 从捕获输出到原始帧的时间间隔是多少, 以及编码器的输出, 当你有了编码帧, 然后是7秒, 其中一个原因是他们有一个巨大的帧缓冲，有72帧, 所以在你做任何事情之前，你需要感受到缓冲, 因为那不是实时编解码器.

追求质量的编解码器, 它们需要帧间预测, 它们有运动矢量, 他们有这样的东西, 需要有几个帧才能进行计算. 实时编解码器, 如果你需要10帧的缓冲, 获取帧的时间是10毫秒, 你已经损失了100毫秒, 只是为了在开始的时候填满你的缓冲区, 这是不可接受的. 所以大多数实时编解码器都是每秒一帧它们会做帧内预测, 和编码, and so on, 但是它们将删除所有需要在缓冲区中有几个帧的内容. 这就是实时编解码器的概念.