Twitch未来五年的视频编码战略:从H.264到 AV1

Easter79
• 阅读 887

今年的NAB2019上,资深编解码技术专家Jan Ozer采访了Twitch的首席研发工程师沈悦时博士,沈博士从编解码器的角度讨论了Twitch对于视频新技术的实践与探索,同时介绍了Twitch未来五年在流媒体技术战略方面的布局。他认为,五年后Twitch的头部以及尾部内容将100%使用AV1编码。

文 / Jan Ozer

译 / 郭俊翔

原文

https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/NAB-2019-Twitch-Talks-VP9-AV1-and-its-Five-Year-Encoding-Roadmap-131163.aspx?from=timeline

Jan Ozer:大家好,我是Jan Ozer。这次我们非常荣幸地请到了Twitch首席研发工程师沈悦时,接下来我们将从编解码器的角度讨论Twitch的研发工作。总所周知,视频编解码器是一个日新月异的领域。你好,悦时,欢迎你的到来。

沈悦时:非常感谢Jan。大家好,我是来自Twitch的悦时。Twitch是一个以电子竞技与游戏直播内容为主的直播流媒体平台,根据twitchtracker.com的公开信息,高峰时我们有14万个直播频道,而在线观众的峰值是400万。由于我们是一个互动直播的平台,所以我们对编解码的低延迟要求很高。同时我们拥有一个庞大的主播社群,直播频道根据受欢迎程度来讲分为头部和长尾两大板块。对于头部主播,我们下个月将部署基于VP9的流媒体直播,等未来生态AV1系统逐渐成熟后,我们会考虑同时传输x264、VP9与AV1格式。由于观众规模巨大,对于头部内容,同时支持多种视频编码器格式是负担得起的:虽然这样做会增加编解码成本,但流量费用的节省使得我们能够实现总体净成本的降低。另一方面,对于低观看率的长尾频道而言,我们只能为它们提供单一格式的流媒体服务,而我们目前长尾频道的编码策略是使用高密度硬件H.264编码的解决方案。但是,我们希望到2024年或2025年,届时AV1生态系统会完全就绪,而那时我们也会实现Twitch平台的百分百AV1化。

Jan Ozer:你说的是2024或2025年吗?

沈悦时:是的,这是我们根据对整个工业界的了解而做的预测。但另一方面,正如我所说,我们希望在2022-2023年实现对头部内容率先部署AV1格式,同时保持AV1与H.264的双格式流媒体传输。对于长尾内容,我们则是希望五年以后,整个生态里所有的设备都支持AV1,届时我们的直播频道无论头部还是长尾都将会百分百切换至AV1。

Jan Ozer:所以Twitch是一个以互联网直播为主的视频平台。你说的头部内容是指用户观看次数最多的直播内容?

沈悦时:是的。比如电子竞技内容和头部主播频道 。

Jan Ozer:好的,所以你们最近一直在考虑转用VP9,用的是硬件编码、软件编码还是二者兼具?

沈悦时:这是一个非常好的问题。我们的着眼点是如何实现VP9的高压缩效率,因此我们现如今使用的VP9编码器是基于FPGA的。而至于软件编码,我们的评估结果是至今为止还没有足够的数据让我们相信软编可以提供类似FPGA的压缩效率。顺带说一句,我们对于实时编码器压缩效率的参考标准是x264 median,对于VP9的期望值是至少能实现25%的码率节省,同时我们下一代的VP9编码器是计划能实现35%的码率节省。

Jan Ozer:好的,您是说使用FPGA编码器生成的VP9 流媒体,在相同画质的前提下,其码率相对x264 median降低了25%?

沈悦时:没错,就是这么回事。

Jan Ozer:好的,同时这是为了实时编码传输吗?

沈悦时:是的,是为了直播的应用。

Jan Ozer:这到是让我想起我们俩几个月前有一个很有趣的、关于你们作为一个直播大平台、对于VBR和CBR利弊的讨论。 你能不能详细解释一下你从一个直播平台的角度,对于VBR与CBR的看法?

沈悦时:好的。先解释一下,Twitch平台是基于我们的私有CDN,也就是说我们有自己的骨干网,以及分发、边缘服务器,同时也和众多ISP有peering的合同。基于我们的实际操作,我们并不欢迎VBR,原因是在于我们通常向ISP预定一个带宽,我们称之为“管道”。 如果视频是VBR的,我们很难计算应该将多少观众放在这个管道里,从而导致我们的服务质量变得不可控。我们直播的情形和点播是截然不同的,点播是不同的观众在同一时间观看不同的内容,而直播则是不同的观众在同一时间观看相同的内容,所以说VBR会混淆我们的观众分配系统,让我们计算不出在某一个管道里应该放多少观众 。

Jan Ozer:通过你的解释,大家对你们平台在观众方的架构有所了解了 。换个话题,对于主播方,你们是从游戏玩家那里获得一路原始音视频流,然后为转码成多个码率,那你们的码率阶梯是什么样的?

沈悦时:是,目前我们接受的原始视频流是1080p 60FPS。

Jan Ozer:码率是多少?

沈悦时:码率取决于主播的上行带宽,通常在6~8.5Mbps之间。然后我们将会转码成720p 60FPS 3Mbps、720p 30FPS 2Mbps,直到160p 200Kbps。

Jan Ozer:好的,那你对客观画质指标有什么看法?你使用哪些指标,对哪些指标是你比较有信心?

沈悦时:好的,这是一个非常好的课题,其实我们现在正进行一些这方面的研究。在现阶段,我们是综合PSNR、SSIM与VMAF考量客观质量,不过我们暂时还是最依赖是我和我同事的主观评测,也就是我们的眼睛。当然PSNR是可以给了我们一些的参考,它能发现一些明显的编码错误,但一半以上的质量评测仍然依赖于我们的眼睛。

Jan Ozer:好的。昨天我与一位大OTT公司的的编解码工程师讨论了如何对于编码梯度中不同的码率选用不同的编码参数,他的观点是对于更低的码率采取降低噪音甚至降低清晰度的编码策略。你们是不是也有相关的研究?

沈悦时:这是确实是一个非常有趣的研究领域,但囿于条件,实际上我们并不尝试对编码做图像预处理。

Jan Ozer:我的读者大部分没有你的技术水平,肯定也没有像我采访的那位专家(编者按,Jan说的那位专家是亚马逊视频的Ben Waggoner,专著”Compression for Great Vid-eo and Audio: Master Tips and Common Sense”的作者)的技术水品。我们大多数人包括我自己对于编码器设置停留在仅仅选择x264 preset的阶段,当然x264 preset本身是包含了很多参数的组合。但是有一个有趣的想法是去研究x264每个具体的设置,比方说低分辩率和1080p或者720p会有不同的要求,毕竟低分辩率的视频是事先做过很多缩放处理的。对此你有什么看法?

沈悦时:关于这一点,我想我们需要在评估此项优化的投资回报率之后才能给出准确的答案。于此同时,实际上我们平台的大多数观众观看视频是1080p 60FPS。

Jan Ozer:没错。

沈悦时:我暂时没有开发此项编码器优化的投资回报率数据。

Jan Ozer:那你谈到你们平台绝大多数的观众观看1080p 60FPS,你能告诉我具体的比例吗, 比如是95%还是62%?

沈悦时:我脑海中暂时并没有一个明确的数字,但我可以保证这个比例一定超过50%,当然这是要视地区而定的,像美国这样有比较好的互联网环境的地区比例一定更高。

Jan Ozer:除了美国之外,你们的主营市场还有哪些?这些国家与地区的占比又是什么情况?

沈悦时:亚太地区是我们十分重视的市场,如新加坡、韩国等都拥有非常不错的网络传输条件。而像拉美、东欧等地区,尽管宽带条件相对较差,也有超过50%的观众观看1080p 60FPS的视频。当然,在美国与西欧地区,这个比例会更高。

Jan Ozer:原来如此,这可能就是你们并没有太大动力在优化低码率音视频流传输上投入过多资源的原因。

沈悦时:是的,不过我们实际上也做了一些关于低码率传输的优化工作。比如说我们之前的160p档是500Kbps,我们通过优化音频码率降低了整个160p档的码率。

Jan Ozer:你有PSNR、SSIM或VMAF的推荐参数吗?

沈悦时:抱歉,这需要视内容而定,我暂时并不想推荐某些绝对的数值。

Jan Ozer:好的,非常感谢沈悦时接受我们的采访,希望您与Twitch能够在未来大展宏图。

沈悦时:好的,非常感谢您。

LiveVideoStack  招募

LiveVideoStack正在招募编辑/记者/运营,与全球顶尖多媒及技术专家和LiveVideoStack年轻的伙伴一起,推动多媒体技术生态发展。了解岗位信息请在BOSS直聘上搜索“LiveVideoStack”,或通过微信“Tony_Bao_”与主编包研交流。

Twitch未来五年的视频编码战略:从H.264到 AV1

LiveVideoStackCon 2019北京正在招募讲师,无论你是技术派还是学术派,亦或是行业专家,无论你的团队有多小、有多新,都可以来申请成为LiveVideoStackCon的讲师。点击【阅读原文】了解更多大会相关信息。

本文分享自微信公众号 - LiveVideoStack(livevideostack)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

点赞
收藏
评论区
推荐文章
blmius blmius
3年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
科林-Colin 科林-Colin
3年前
下一代前端构建工具 Vite (中英双语字幕)
关于 Vite,来看看作者本人怎么说。本视频是Vue以及Vite作者 尤雨溪 在2021年2月12日在Twitch上做客GitHubOpenSourceFriday节目的直播视频。在视频里有尤大关于Vite的各项功能的详细阐述、大神在线编码、在线Debug、大佬disswebpack以及对Vite的哲学思考。
皕杰报表之UUID
​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为
待兔 待兔
5个月前
手写Java HashMap源码
HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程22
Jacquelyn38 Jacquelyn38
3年前
2020年前端实用代码段,为你的工作保驾护航
有空的时候,自己总结了几个代码段,在开发中也经常使用,谢谢。1、使用解构获取json数据let jsonData  id: 1,status: "OK",data: 'a', 'b';let  id, status, data: number   jsonData;console.log(id, status, number )
Easter79 Easter79
3年前
Twitter的分布式自增ID算法snowflake (Java版)
概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移
Wesley13 Wesley13
3年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Wesley13 Wesley13
3年前
VP9如何给Twitch的电竞直播带来价值?
本文来自Twitch的科技博客,详细解读了该平台如何将VP9用于其电竞赛事的直播。通过FPGA硬件加速,VP9能极大提升视频直播服务的质量。LiveVideoStack对原文进行了摘译,感谢Twitch的首席研发工程师沈悦时博士提供的技术审校。文/ AkrumElkhazin,VideoAlgorithmArchitect,NG
Wesley13 Wesley13
3年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
Python进阶者 Python进阶者
11个月前
Excel中这日期老是出来00:00:00,怎么用Pandas把这个去除
大家好,我是皮皮。一、前言前几天在Python白银交流群【上海新年人】问了一个Pandas数据筛选的问题。问题如下:这日期老是出来00:00:00,怎么把这个去除。二、实现过程后来【论草莓如何成为冻干莓】给了一个思路和代码如下:pd.toexcel之前把这
Easter79
Easter79
Lv1
今生可爱与温柔,每一样都不能少。
文章
2.8k
粉丝
5
获赞
1.2k