李安琪（阿里巴巴）： slides和会议记录会后将会公开
... 大家有顾虑可以跟W3C的同学沟通
[自我介绍 姓名-公司]
朱红儒（阿里巴巴）： 介绍W3C的核心标准
... WebRTC、WebAssembly、WebXR、Houdini 等新的标准工作
... WebAuthn使用了FIDO的验证技术
[展示W3C 的中国参与历程]
朱红儒（阿里巴巴）： 中文兴趣组成立于去年九月
... 期待大家以后可以参与 W3C 的技术会议和各大新技术标准工作组
[介绍Chinese Interest Group的历史]
朱红儒（阿里巴巴）： 小组主席来自于百度、Intel、华为和阿里巴巴等
... 中国标准走向国际需要大家共同努力，可能会遇到很多困难
... 如电话会议，需要中国发出声音，要求对东亚友好的时区
... 大家需要把requirement和use case积极地提出来
... 尤其是中国特色的用户体验
... 例如支付场景的web标准落地
... 希望大家大胆地输入你们的use case
... 然后按照流程影响标准的技术走向
... 如W3C有自己的工作流程
... Chinese IG可以帮助大家把观点输入到W3C
... 无障碍访问也是国际非常重视的标准
... 对产品在海外合规落地很重要
... 如泰语和越南语的呈现
... 阿里一直期待与大家在这方面开放合作
... 差旅顾虑
... 可能受到政治国际关系影响
... Web 媒体相关标准
... 渲染、设备、分发、处理等
... W3C标准更注重应用层面的API
... 标准的输出方式，可以先寻求最大公约数
... W3C 跟媒体相关的工作组和兴趣组
... 很多标准跟大家的工作紧密相关
... 大家可以提交到孵化小组、研讨会，或者共同合作一个方案
... W3C在中国也有团队帮助大家输出方案
... 期待大家度过一天愉快的技术讨论
François Daoust (W3C): 我在W3C主要负责媒体娱乐相关的工作
... 非常期待大家今天的技术实践细节、用例等
... 我先为大家介绍一下W3C在媒体娱乐方面的技术方向
... 这是W3C在媒体发展方向的一个文档，由很多媒体公司共同维护
... 这三个概念是我们在媒体工作的几个重点
... Timeiline
... 持续媒体
... 可交互内容，包括游戏
... 持续媒体，工作组一直关注于媒体流
... 媒体，我们关注两个方面，预订阅和实时媒体
... timeline可能依赖于用户的交互
... 预订阅是传统形式的媒体，用户选择自己想看的内容
... 未来的几个趋势
... 减少设备碎片化呈现
... web技术每天都在持续更新
... 媒体娱乐行业也在持续拥抱新技术，如可交互的内容
... 另一个新趋势是，持续提高的媒体质量
... HDR 图像
... 还有一个趋势是媒体的发布, move to IP
... unicast,、CDN 优化、WebRTC、降低延时
... IP 取代 SDI，提供以前不可能的功能
... 还有一个众所周知的趋势，个性化定制
... 这是一个个性化阅览和线性内容的协作
... 另一个技术难点是虚拟现实交互媒体
... 还是试验性阶段
... Media的下一个技术兴奋点（Next Big Thing）
... 我不能预测未来，但这是我们过去一直在努力探索的技术方向
... MSE流媒体
... 个性化更好地留住用户
... AI和机器学习实时分析用户习惯
... Web 有很好的安全保障机制
... 用户如何安全地分享内容
... 大家可能感觉我们没有在用web，一直用微信分享
... 但这背后的技术可能还是链接
... 用户的交互将会影响最终媒体内容的合成或者剧情的构造
... 电子竞技、游戏直播
... web是一个很好的分享感受的平台
... 最近的GDC活动的一个热门话题是云游戏
... BBC制作了一个VR电影
... 并非传统电影，没有音轨和视轨
... 以动画形式呈现，需要headset
... WRC，可以线性交互
... 可以选择你想要的摄像机角度
... Late Shift
... 用户可以通过手机投票选择剧情
... Detroit: Become Human，游戏和电影的界限变得模糊
... 如果我们认为这些是媒体娱乐的未来
... 要实现这个未来，以下是一些我们需要实现的技术
... Web XR、WebGPU、WebAssembly、机器学习等
... 还有一些检测用户行为的接口
... W3C 最近在筹备一个游戏研讨会
... 探索下一代的游戏技术
... 期待大家参与
徐嵩（中国移动-咪咕）： 大家好，我叫徐嵩
... 不知道去年11月在杭州的会议有没有人见过我
... 接下来我会把去年讲的提纲过一下
... 为大家介绍一下媒体与娱乐兴趣组的目标和范围
2018年11月17日，W3C Web 中文兴趣组面对面会议纪要：https://www.w3.org/2018/11/17-chinese-web-minutes.html
徐嵩（中国移动-咪咕）： 媒体与娱乐工作组正在筹建
... 接下来会对之前Francois讲的细节进行描述
... 其中包括Media Capabilities
... 允许网站为用户选择媒体内容是做出最佳匹配
... 接下来是画中画
... 允许网站始终在其他窗口上显示浮动的视频窗口
... 允许用户在各网站进行视频清晰度切换
... Autoplay Policy Detection 视频自动播放策略
... Move to IP 包含两部分
... 第一部分是Distribution over IP
... 主要目的是为了提升视频播放时延，企业会将CDN节点下沉到边缘计算节点
... 第二个是P2P CDN
... 另外一个趋势是低延时技术（Low-latency technology）
... 主要基于5G来实现
... 5G通过切片技术来保证带宽
... 通过网络切片之后，能为实时性高的服务提供带宽保证
... Move to IP 最后一部分是云化的处理
... 包含信号预检、回源、播控、转码、流媒体服务等功能
... CDN下沉到MEC是云化的一种操作
... Web 视频解码也可能下沉到边缘计算节点
[演示图：基于Web 的超高清视频使用5G和MEC（移动边缘计算）技术]
徐嵩（中国移动-咪咕）： 通过5G基站，传输到5G核心网，通过视频流推送到视频云端服务器，云端进行编解码分发、分发到CDN，CDN分发到MEC边缘节点，最后分发到用户终端设备上
... 接下来是对现在的编辑草案进行一些补充
... 比如一些开放式的问题
... 现金流是否能体现行业趋势？
... 是否应该描述行业生态链中不同角色：内容生产商，广播运营商，CDN服务者，解决方案提供商，设备制造商
... 如何考虑与商业成功的一些其他因素：公共服务，技术监管？
... 是否有缺失的媒体娱乐Web 技术？
... 融媒体具体场景定义是否太宽广或太狭窄？
... 融媒体概念更多的出现在政府工作报告和政府的行业发展描述里面
... 广电、电信、互联网企业三网合一？
... 另外是每个成员公司提供更多的商业使用场景，可以输出给W3C中国Team或者媒体工作组
... 大家有什么问题吗？
安勍（阿里巴巴）： 刚才说要成立工作组，可以介绍一下现在情况吗？
徐嵩（中国移动-咪咕）： 可以让Francois来介绍一下
François Daoust (W3C): 这个工作组的主要争议点在EME规范
... EME标准是关注如何保护视频版权，和DRM有关
... 主要的浏览器和内容厂商都愿意实现和使用这个规范
... 但也有人认为这个规范制约了Web的开放发展
... 我们还在倾听W3C会员对这个工作组相关规范的意见
李安琪（阿里巴巴）： W3C在发布EME的时候国际上有很多争论
... 现在工作组要不要加上EME还在讨论
... 如果企业和W3C管理层对这个问题有争议的话，可能工作组筹备时间会长一些
徐嵩（中国移动-咪咕）： 之前在视频制作内容引进时需要有DRM的保护
... 现在HBO内容在引进国内时得到了中国版本的DRM的保护
王天笑（知乎）： EME在Netflix已经用了5、6年了，怎么看待这个？
徐嵩（中国移动-咪咕）： 个人认为最终取决于内容生产制造商
吴小倩（W3C）： 这里讨论的EME是EME的下一代标准，当前的标准已经是正式推荐标准了
楼剑（阿里巴巴）： 阿里巴巴RTC这个方向伴随集团业务逐渐成长，有超过5年的历史
... 技术在集团内合到一起，内部和公有云都用的同样的技术
... 我们团队和钉钉团队有合作
... 钉钉团队之前视频会议采用的是非WebRTC的标准
... 去年在钉钉内部成功上线了RTC服务，持续打磨网络和视频质量等方面的技术
... 收到了很多反馈，并持续改进
... 阿里内部有一个阿里郎的会议系统
... 也采用了RTC技术
... 最近几年RTC的爆发来自于娱乐行业
... 阿里有两款产品：淘宝直播和来疯直播，都用了RTC技术
... 另外一部分是最近几年流行的智能硬件
... 包括零售终端、天猫精灵等，主要通过RTC做一些包大小裁剪
[视频技术介绍]
楼剑（阿里巴巴）： 一个是音频3A算法，淘宝和钉钉进行5000+设备类型的适配
... 视频编解码后面逐步展开讲，主要应用自适应带宽编码和多层编码
... 最后是弱网对抗，后面再展开讲，因为互联网的丢包和网络抖动是不可避免的
... 我们近几年通过收集大量的噪声模型，进行降噪
... 回声消除是另一个重要的音频处理技术
... 发现有些硬件自带回声消除，但部分做的方法是错误的，部分需要改进
... 回声消除算法还在持续演进
... 视频编码的技术积累以前不是在RTC领域
... 有全高清、高清、流畅三种屏
... 如何把用户感兴趣的部分凸现出来
... 屏幕共享案例中其中夹杂了太多技术，让技术复杂度变高
[Demo: 几乎相同的视频质量，码率降低40%以上]
... 人眼关注细节增强]
楼剑（阿里巴巴）： 通过图像处理算法，突出人眼感兴趣的区域，突出和锐化
... 自研的ARWNT（阿里巴巴弱网对抗算法）
... 思路是通过场景识别分析出拥塞和网络抖动造成的原因，调整对应的策略
... 阿里云视频服务全网架构
... 与合作伙伴正在搭建海量的边缘计算节点
... 实现实时的音视频传输网络
... 回顾一下，为什么构建云上的RTC？
... 自建相对于云RTC有几个问题
... 业务弹性差，资产重、成本高，可用性差
... 阿里云RTC场景支持情况
... 自定义媒体加密：观察中
... 文件共享：暂无计划支持
... Mobility：支持
... IoT：调研中，计划支持
... ICE：支持，内部应用中
... 分层编码，多帧率：已支持
... 大家有什么问题？
胡皓（腾讯）： 阿里云在低延时上做了什么优化？
楼剑（阿里巴巴）： 网络良好情况下，250ms之内
... 网络情况差的时候（弱网）会调整buffer，尽量控制在400ms之内
... 屏幕共享场景：内容难编码，需要保证屏幕质量，需要做一些延时调整，但不超过1.5秒
徐嵩（中国移动-咪咕）： 人眼关注细节增强是如何识别的，使用的是数字技术还是生物技术？
楼剑（阿里巴巴）： 分为信号处理和机器理解
... 高层机器理解，会对人眼感兴趣的区域进行机器学习理解
... 我们在与清华合作，进行用户眼球实验评估
[休息20分钟]
诸剑俊（英特尔）： 大家好，我是来自Intel的诸剑俊
... 我会讲一下QUIC的概述、QUIC在WebRTC上的应用以及QUIC的实践
... QUIC建立连接的速度非常快，会把加密的过程在握手的时候一起完成
... 多路复用
... 比如我们在访问一个页面的时候，会访问很多资源
... 当一个TCP包丢了的时候，会导致后续的包等待
... QUIC不存在这个问题
... TCP是由一个五元组标识的
... QUIC使用的是连接ID
... QUIC在WebRTC场景里有两种类型：P2P和C/S模式
... 目前在ORTC CG里做
... 我们希望能够把媒体流运行在QUIC上
... 这需要对非可靠传输的支持
... C/S场景
... 我们的产品会有一个服务器
... 目前WebRTC是基于ICE的
... 如果有C/S模式的QUIC，可以提高首帧的连接速度
... 可以让WebRTC和HTTP共享一个连接
... QUIC的传输协议是在IETF制定的
... 如果我们想让媒体运行在QUIC上，需要把P2P的部分替换为media engine
... 介绍一下OWT
https://github.com/open-webrtc-toolkit
诸剑俊（英特尔）： 主要做QUIC在两个方面的应用：节点间传输和客户端和服务器的连接
... 目前Chrome支持QUIC，不过支持比较有限
... RTCQuicStream
[展示在不同的丢包环境下对TCP和QUIC的比较]
[展示服务端各节点间内部通信时TCP和QUIC的对比]
@@: 为什么可以不用STUN和TURN？
诸剑俊（英特尔）： P2P场景需要STUN和TURN增强连通性，C/S架构中一般可以不用STUN和TURN
徐嵩（中国移动-咪咕）： 除了单播以外，还可能会涉及到混播
... QUIC是否不支持组播/多播？
诸剑俊（英特尔）： 目前我们还没有尝试过这类应用场景
... 我们的应用场景以Web为主，对广电场景探索不多
... 广电场景对加密是必须要求的吗？
... @@
... QUIC可以做一些拥塞控制之类的事情
@@: 关于刚才的TCP和QUIC的对比，为什么QUIC的效果会比TCP好？
诸剑俊（英特尔）： 我们简单做了一些实验，在某些环境下（比如5%丢包的时候）包到达时间比较平稳，但也没有在各方面显著超越TCP。
François Daoust (W3C): 关于encoder/decoder API
... QUIC可以作为data transport
... 但也需要访问浏览器的encoder/decoder API
... 目前还没有相关的标准，欢迎大家的输入
刘大鹏（阿里巴巴）： 我们现在的实践是使用HTML，建立WebRTC通道、ICE，再建立QUIC的连接
陈超（腾讯）： 现在QUIC over WebRTC在生产环境的使用可能性？浏览器支持？
诸剑俊（英特尔）： Chrome有实现，但是behind a flag
@@: 注意到您用的是C/S，不是B/S，WebRTC可以在各平台上使用了吗？
诸剑俊（英特尔）： 可以的，在各平台上都已经比较成熟了
@@: 点播的用例？
诸剑俊（英特尔）： 在媒体服务器上建立一个QuicStream进行可靠传输
@@: 带宽的是否有增加？
诸剑俊（英特尔）： 我觉得不会有太大的增加，不过我们没有测试
Edited: 当天和其他参会者沟通后了解到流量的确有增长，会议结束后和Intel的同事沟通也观察到有类似情况
[展示demo]
姚穗斌（腾讯）： 为什么我们要用<video-image>？
... 显然，因为video和img都不能完成我们想做的事情
... video需要用户点击（不能自动播放），不能小窗播放，部分国内浏览器也不支持多个视频同时播放
... 而GIF文件太大，流畅度不佳
<video-image src="foo.mp4">
姚穗斌（腾讯）： 支持自动播放，不会有声音（即使视频本身有声音）
... 那么问题来了，截取小视频会增加运营成本吗？
... 有两种解决方法：
... 1) 使用Media Fragments API，这样只会下载视频的头部和播放的部分，而现有的浏览器会一直下载视频文件，造成带宽浪费
... 2) 使用CDN动态截取
[展示 <video-image> 的属性]
姚穗斌（腾讯）： 我在写这个提案的时候一直在思考，是否需要这个新的元素？
... 另一个方案是放宽video元素的限制：允许静音自动播放和多个视频同时播放
... 原声Safari和Chrome已经支持，但是大部分国内浏览器还不支持这两点
... 自动播放带来的问题：骚扰用户
... "Chrome's autoplay policy: muted autoplay is always allowed"
... 消耗用户带宽
... W3C的WCAG标准也有这方面的规定
... 我们还可以实现半透明视频
... 现在我们使用雪碧图实现的东西以后可以使用视频实现，而且素材大小也比较小
... 以上是video-image提案
... 下面是增加video基础API的建议：增加bufferTime属性，让开发者控制视频缓冲大小
... 应用场景一：短视频feed默认缓存首帧画面，提高起播速度
... 应用场景二：互动视频，提前缓存下一个视频的前几秒
... 我们希望video会有更详细的错误码
... 目前的MEDIA_ERR_DECODE有可能是404、403、200（无法解码）、CSP限制等很多种可能
... 希望添加bytesReceived属性，获取当前已下载数据量
@@: 一个页面如果有10个视频，浏览器编解码可能会带来耗电量的问题
姚穗斌（腾讯）： 这是个很有意思的问题，我还没有测试视频和GIF的哪个耗电量更大，打算将来测试一下
罗智勇（阿里巴巴）： video的自动播放的问题在video-image里也是会有的
姚穗斌（腾讯）： 滥用的问题是需要网站开发者解决的
罗智勇（阿里巴巴）： 这样的话和video没有明显的区别
姚穗斌（腾讯）： 所以也可以把这个直接加到video里
尹志达（爱奇艺）： 是否可以把GIF的功能提升，来解决这个问题？
... 比如GIF的大小太大的问题，开发一个新格式
姚穗斌（腾讯）： 这是一个可能的方案
... 但是涉及到编解码器、各浏览器厂商的支持问题
吴小倩（W3C）： 错误码的问题是跨域的原因还是错误不够详细？
姚穗斌（腾讯）： 主要是因为浏览器底层的错误码分类不够细
... 我认为也有跨域保护的影响
刘忠彬（面包理想）： 改进video元素是否会比添加一个新的video-image元素得到浏览器厂商的支持更快？
姚穗斌（腾讯）： 同意，video-image是一个解释问题的方法，我也觉得改进video元素是更好的方式
[午餐时间]
李安琪（阿里巴巴）： 关于弹幕，去年11月的会议上我们讨论过一些内容
... 今天可以更进一步的讨论技术的细节
... 这是一个东亚独特的需求
... 在走出去之前，希望我们能现在国内有一个共识
徐嵩（中国移动-咪咕）： 希望我们能达到一个共识，让欧美的人们知道在东亚有“弹幕”这么个概念
... 我第一次在Media & Entertainment Interest Group介绍弹幕的时候，大家都不知道弹幕是干什么的
... 我拍了一些大家看带弹幕的视频的例子
... 首先，说一下弹幕的定义
... 弹幕的英文单词有很多，bullet subtitles, bullet screen, commentary subtitles, danmaku, barrage等等
... 指的是看视频的时候飘过去的评论
... 我们想做的事是梳理一下弹幕的场景，也让之后bilibili的同学分享的时候能更轻松
... 弹幕能够让用户有更深的参与感
... 文化、流行对年轻的用户很有吸引力
... 年轻用户喜欢多任务，比如一边看视频一边刷微信
... 我列出了两篇论文，讨论年轻用户为什么喜欢多任务和弹幕这样的功能
... 年轻用户有一种孤独感
... 不只是东亚的用户，也包括美国和欧洲的用户
... 这项技术本身并不难，有各种实现方式
... 从远程服务器抓取评论信息，通过DOM或canvas绘制并层叠在视频上
... 需要计算弹幕的位置
... 以前只要考虑弹幕之间不互相碰撞，现在也需要避免弹幕和视频中的关键人物的碰撞
... 需要提取关键帧，利用人工智能判断关键人物在关键帧中的坐标
... 为什么要做标准化？
... 需求很普遍，也能降低开发难度，统一弹幕结构
... 如何进行标准化？
... 1) 搜集用户场景
... 我们在GitHub里也分享了一些这方面的工作
... 也欢迎大家的反馈
... 2) 写一个兴趣组的note
... 3) 编写具体的技术细节和API文档
... 4) 向WICG提交topic，邀请浏览器厂商进行讨论
... 刚才茶歇的时候，我和W3C中国的员工进行了讨论，也得到了很多的反馈
... 标准的建议：制定弹幕的标准格式，通过video下的track标签引入，绘制弹幕
... VDT文件格式（名字待讨论）
... JSON的格式
... 媒体和娱乐组其他相关用户场景：视频清晰度切换、多语言字幕、视频大点、VR和360视频
... 大家有什么问题？
李安琪（阿里巴巴）： 弹幕标准化的商业价值？
徐嵩（中国移动-咪咕）： 降低成本
... 可以降低扩展新功能的成本
... 虽然不能直接增加企业的收益，但是也可以降低成本
姚穗斌（腾讯）： 这个标准比较像字幕
... 有没有可能在字幕的标准上增加运动轨迹进行扩展？
徐嵩（中国移动-咪咕）： 这也是一种不错的尝试方式
谭兆歆（bilibili）： 我们在和小程序对接的时候，小程序自己也带一套弹幕系统，但是不符合我们的要求
... 因为没有弹幕的标准，他们也不知道该改成什么样子
... 如果有了一套标准，大家也知道该怎么实现
François Daoust (W3C): 你是否期望浏览器是否渲染这些弹幕？
... 目前我们得到的反馈是浏览器不愿意实现更多的字幕功能，即使是对WebVTT的支持
... 浏览器更希望的是暴露一些hook，让Web应用去扩展
... 当然，这不是说一个标准的格式没有意义，建议可以看看data queue标准，之前浏览器不感兴趣，但媒体厂商重申这个规范对他们是必要的，所以现在重新开始考虑实现
徐嵩（中国移动-咪咕）： 谢谢，你的评论很有用
陈超（腾讯）： 刚才提到的VDT格式是否支持直播场景？
徐嵩（中国移动-咪咕）： 目前不支持，我们目前只想支持一个最小化的版本
谭兆歆（bilibili）： 关于弹幕，我觉得最先标准化的是弹幕的名称（笑）
... danmaku, danmu, bullet subtitles等等
... 弹幕在日本被称呼为评论（コメント），只有在大量评论出现在屏幕上才被称为弹幕
... 但为了不和普通的评论搞混，我们只称其为弹幕
[展示demo]
谭兆歆（bilibili）： 对于bilibili来说，现在的用户对于弹幕的玩法和体验有了更多的要求
... 总结一下bilibili弹幕的特性：
... 1) 不重叠
... 每种模式处于不同层，每种模式也可以有很多层，但是互相之间占位都不会重叠
... 2) 如果弹幕区域和渲染的列表固定不变，那么出现的位置和顺序都是固定的
... 3) 弹幕并不仅依附于视频而使用，也可以出现在各种活动当中
... 我们最初是按照这七个维度设置了默认属性：字体、间距、阴影、透明度、速度、字号、颜色
... bilibili支持十几种弹幕的样式和筛选方式
... 不同浏览器底层对不同弹幕的渲染方式消耗不同
... bilibili还有「不同画风」的弹幕，这类高级弹幕封装了一些动画的API，供用户来选择
... 另外我们还设计了一套所见即所得的弹幕语言（bas），具有高度的交互性
... 我们也有「弹幕大赛」来丰富我们的弹幕生态
... bas (bilibili animation script danmaku) 已经开源在 GitHub 上
... 我们的封面弹幕和活动弹幕可以脱离于视频使用
... 弹幕蒙版，基于CSS的mask-image属性
... 我们也在做高级弹幕和BAS弹幕的推广
... 做一些周边产物，比如BAS编辑器
... 关于对弹幕标准的思考，刚才提到的小程序案例是一个弹幕实现的成本比较高的例子
... 1) 标准化弹幕的默认排版方式
... 2) 希望可以给弹幕提供一个专用的容器，如<danmakulist>、<danmaku>，或者添加CSS的display: danmaku
... 直排古文弹幕
... 希望能在画中画中增加弹幕和字幕的能力
... 希望增强CSS mask-image的能力
... 让各浏览器的实现更加完善一些
... 我们希望和大家一起推进弹幕标准化的工作
... 想问一个问题，在座的各位有多少使用过bilibili？
[绝大部分参会者都举了手]
谭兆歆（bilibili）： 关于Firefox的性能，在高并发的情况下，CSS弹幕比canvas弹幕的资源占用高1倍左右
... 2D canvas的能力不足，不能做Y轴旋转，我们在考虑使用WebGL
陆禹淳（声网）： 我们公司比较注重音视频的实时传输
... 弹幕在实时的情况下是否有和音视频同步的需求？
谭兆歆（bilibili）： 我们是按批次处理的，每秒处理一批，因为对实时的要求不是特别高
陆禹淳（声网）： 是否考虑到弱网？
谭兆歆（bilibili）： 目前还没有，不过有断线重连的机制
吴小倩（W3C）： 你们是否探索和总结过机器学习在弹幕方面的使用？还有VR弹幕？
谭兆歆（bilibili）： 我们支持VR弹幕，但是没有进行深入的研究，会等VR技术更加成熟
François Daoust (W3C): 关于画中画，这是Media WG工作的一部分
... 目前的画中画功能很有限
... 曾经有人提过关于画中画字幕的提议，但是浏览器厂商目前没有兴趣实现
... 如果我们能够坚持向工作组输入需求的话，这个还是很有希望的
黄之昊（bilibili）： 我们也希望通过画中画实现一个全局播放器
... 切换到其他的页面时，这个视频能够继续播放下去
... 这个可能不符合画中画的初衷，但是我们的一个想法
谭兆歆（bilibili）： canvas提供的只是一个容器，真正的逻辑我们是单独处理的
王天笑（知乎）： 可以讲一下避免遮挡人物是如何实现的吗？
谭兆歆（bilibili）： 后端机器学习分析人物生成遮挡路径，前端解析成base64 SVG，填入mask-image里
... 我们不仅训练了人像，还有猫、动漫图像等很多东西
赵磊（中国移动-咪咕）： 感觉BAS有点像Python，也有点像Ruby，为什么要这样设计？解决了哪些问题？
谭兆歆（bilibili）： Flash版播放器就包含「代码弹幕」的功能
... 但是这个不能直接移植到HTML5播放器下，因为会有安全问题
... 所以我们需要定义一套既有「代码弹幕」的功能，也能够解决安全问题的方案
罗智勇（阿里巴巴）： 关于弹幕的审核
... 除了弹幕格式的标准，我们还需要弹幕审核的标准
谭兆歆（bilibili）： 我觉得这是一个服务端健全的问题
... 服务端会判断弹幕是否合法，如果合法则下发到客户端进行渲染
... 这个在每个公司的实现是不一样的
罗智勇（阿里巴巴）： 浏览器和服务器端都应该有责任
@@: 有一个痛点
... 比如「我很喜欢这个人的弹幕，我如何认识他/她？」
谭兆歆（bilibili）： bilibili的弹幕是实名的，但是对用户ID进行了加密
徐嵩（中国移动-咪咕）： 我也很想「点发弹幕的人」的这个功能
... 但是各个公司有各个公司的策略
谭兆歆（bilibili）： 这是一个产品方面的问题，我觉得不需要放在弹幕标准里进行讨论
丁建强（bilibili）： 今天的分享主要分为三部分，MPEG-DASH的选型、实践和对标准的建议
... MPEG-DASH是一个通过HTTP服务器高质量传输动态自适应参数的媒体信息的技术
... 我们选择MPEG-DASH的原因是其为开放标准，技术上也有一些优势
... 平时看bilibili的同学应该知道，右键可以查看相关信息
... 我们使用了开源的dash.js
... MPD是MPEG-DASH码流构成的XML文件
... 首先我们对manifest文件使用JSON
... 另外经过了多轮优化
... 我们不知道拉流完成和MSE初始化哪个先成功，所以我们会适配两种情况
... DASH播放器支持三种切换码率的策略：abrBola、abrThroughput、abrDynamic
... 动态缓冲区策略
... 在进行生产环境错误率优化改造时，遇到了很多问题，因为生产环境很复杂，用户网络经常会出问题
... 对于网络抖动，我们进行了超时处理
... 对于相关标准的建议，我们希望在HTMLVideoElement.getVideoPlaybackQuality()中新增firstFrameTime（首帧时间）和bufferTimes（卡顿次数）
... 还有就是今天提到多次自动播放策略
... 还有希望获取总共可使用MSE的内存上限
@@: DASH的浏览器支持？
丁建强（bilibili）： 支持MSE的浏览器都支持
@@: 视频预取支持？
丁建强（bilibili）： Web端支持，移动端目前不支持
... 我们会使用Vue进行SSR
张威（新浪）： 刚才对比了DASH和HLS等流媒体协议
... 腾讯和爱奇艺都实现了无缝切换分辨率，都没有使用DASH，为什么bilibili采用了DASH？
丁建强（bilibili）： DASH的标准是开放的，支持的编码也更多，服务器存储成本更低，切片也更灵活
张威（新浪）： 自动切换分辨率时的策略？
丁建强（bilibili）： 关于abrBola，比如设置了40s的buffer，满buffer时我们不会进行操作，当buffer小于10s时我们会降低码率
王天笑（知乎）： 用户的网速是会变化的
丁建强（bilibili）： 我们不看瞬时速度，而是对最近请求的4-10个分片计算平均值
... 也有buffer管理
François Daoust (W3C): getVideoPlaybackQuality的提案很不错
... 你们是否有对MSE的改进建议？
... 关于Fetch，是否有什么使用时的问题？
丁建强（bilibili）： 部分浏览器比如Safari对MSE和Fetch的支持都不够好
François Daoust (W3C): 对于标准是否有什么建议？
丁建强（bilibili）： 目前没有
[休息20分钟]
[美颜demo展示]
吴子敬（小米）： 使用场景——支持公司内部会议
... 视频采集、encode/decode、回声消除、音频编码、音频播放
... 小米直播是最早一批支持主播连麦的平台
... 一台24核的服务器可以支持5000人
... 电台方案融合了实时通话与直播技术
... 小米的发布会会使用CDN推到第三方平台，比如爱奇艺
... 遇到的问题很多，比如丢包、AEC（回声问题）
... 声音通过房间的反射会传回到麦克风里，导致会听到自己的声音
[演示AEC的demo]
吴子敬（小米）： WebRTC应该提供对音频进行处理的方法
[展示客户端推流架构]
吴子敬（小米）： 还有播放器端的唇音同步
[展示播放器快速seek的demo]
[展示音频处理demo]
吴子敬（小米）： GPU图像处理，如美颜
... 我不认为H.264和H.265的功耗会低
... 我们的测试结果是功耗会更高
黄之昊（bilibili）： 刚才提到的能力里，哪些可以在HTML5提供，哪些可以在app里提供？
... 我比较好奇的是人脸贴纸
吴子敬（小米）： 这个对GPU的消耗比较大，可以用WebGL
François Daoust (W3C): 关于刚才快速seek的demo
... 目前使用MSE不能控制浏览器的buffer
吴子敬（小米）： 这个demo是在native app上的
... 另外，快速seek不是精确seek的
... 我们也在和Web团队的同事讨论把这个移植到Web版上
王天笑（知乎）： 大纲：
... MSE介绍
... MSE实践
... 知乎播放器
... MSE 是允许JavaScript生成用于播放的媒体流
... 可以实现切换音频语言
... 动态平滑切换清晰度（例如YouTube）
[MSE 运行流程示意图]
王天笑（知乎）： 知乎使用MSE遇到的问题
... 卡顿次数多
... 首帧延时长
... 无法自动平滑切换清晰度
... 知乎Web播放器使用MSE的实践
... MP4文件->首次请求（Meta信息）-> MP4 Demuxer转换->请求视频信息->转换为FMP4->播放
... 主要问题是MP4怎么转化为FMP4
... 解析video box 和 audio box进行一一转换
... 讲一下怎么实现预缓存
... 浏览器预缓存有限制
... 想自定义的话可以通过MSE进行控制
... 第二个是实现动态切换清晰度
... 目前是通过网速
... 用户手动切换或者通过网速检测需要切换->解析moov box->将视频文件切割出来，进行切换
[MSE浏览器兼容性 Can I use...]
王天笑（知乎）： Safari PTS问题
... 通过Buffered.start 拿到当前视频时间
... Safari上获取不正确
... 通过进行固定偏移来workaround
... 开发时遇到最大的问题是MediaError
... 获取不到视频错误的信息
... 开发比较痛苦，难以定位
... 几个例子
... appendBuffer后时间轴错乱
... 另外一个问题是seek error
... 快速seek多次后MSE就错误了
... 原因是因为seek之前需要abort
... 第三个是media error
... 网上文档很少
... 第四个是未知错误，报错但不影响播放
... 最后是知乎视频播放器：griffith
https://github.com/zhihu/griffith
[介绍项目结构]
[介绍播放器功能和UI]
[介绍事件系统]
[介绍使用方式]
[介绍 standalone 模式]
谭兆歆（bilibili）： 想知道你们是怎么做首帧优化的
王天笑（知乎）： 首先是使用场景，知乎视频都比较小
... 主要是做预加载
谭兆歆（bilibili）： 另外一个问题是转MSE有没有遇到音画不同步的问题
王天笑（知乎）： 有遇到，暂时还没解决。计划的方案是解析存在这个问题的时候当做非MSE来处理
朱国玺（百度）： 移动端怎么优化的？
王天笑（知乎）： 播放器不支持MSE，只支持正常的播放行为
... 播放器不支持移动端的UI
... 播放器不支持移动端的UI
@@: 在前端转FMP4是怎么转的？现加载MP4头还是整个加载完转换？
王天笑（知乎）： 一开始加载的时候不知道视频长度，先给一个固定值加载前面box的内容，拿到mov box size以后，会重新把mov box加载回来
... 没拿到mov box size的case比较少
银国徽（字节跳动）： 大纲：
... 背景介绍
... 技术难点
... 解决方案
... Q&A
... 做播放器的动机：
... 体验（无缝切换）和成本（流量节省）
... 通过两个video切换不能保证视频和音频严格通过
... 同时会造成巨大内存开销
... 两个原始的MP4格式，直接设置SRC无法实现无缝切换
... 浏览器的缓冲也不受代码控制
... 用户在看视频时不一定全部看完，视频不需要全部加载，另外一个用户需求是seek，seek时候会带来流量的巨大消耗。
... 基于以上几个点，做了视频播放器
... 技术难点
... 原生video不支持HLS和FLV
... 常规MP4也不支持无缝切换
[展示视频格式浏览器兼容列表]
银国徽（字节跳动）： 第二个难点是原生video不支持缓冲，无法做到无缝切换的体验
... 主流视频格式：MP4 TS FLV
... 介绍一下 MP4 和 FMP4 的区别
... 为什么MP4不支持流式加载？
... FMP4支持某一个range的播放
... 接下来是TS格式
... TS分为三层：TS层、PES层、ES层
... ES层是真正的音频和视频数据
... 接下来是FLV
[展示FLV结构示意图]
银国徽（字节跳动）： 接下来是解决方案
[MSE处理示意图]
[展示解决前与解决后的network抓包示意图]
银国徽（字节跳动）： 服务器上没有变更
... 是前端播放器的优化
... 主要通过控制视频的缓冲和加载来实现
... mp4到播放需要通过一个加载队列
... 存在浏览器http并发请求限制问题，所以需要使用加载队列
... 区分哪些是有效请求，哪些需要abort
... 第二个是解析器，可以解析多种格式的视频
... 视频质量好坏，播放卡不卡顿，依赖解析器的算法
... 重点讲一下解析器
... Demux包括：moov、Mdat、Range
... seek时候需要严格控制Demux解析
银国徽（字节跳动）： TS Demux包括：TS、PES、ES
... 如何实现无缝切换？
... 如何对齐时间点？
... 基于IM来对齐，通过逆向算法推算出另一个视频的IM
... 播放器已经开源
https://github.com/bytedance/xgplayer
银国徽（字节跳动）： 提议：
... 希望浏览器能内置多媒体对象，如MP4、FLV、TS解析
... 希望浏览器能开放FFMPEG接口
... 原因是基于以下几个场景：视频上传、视频编辑、视频特效、视频合成
... 视频编辑场景：很多公司在做云剪辑，西瓜是通过前端来做视频剪辑的
... 视频合成需要借助FFMPEG的能力，不开放的话只能通过WASM来做，来消耗很大
... 问题？
@@: 视频特效主要考虑支持哪些特效？
银国徽（字节跳动）： 实现哪些特效出于业务需求来考虑实现
丁建强（bilibili）： 无缝切换的时机是什么时候？
... 在什么时候切换为真正的清晰度？
银国徽（字节跳动）： 切换以后把多余的sourceBuffer移除，再将新的填入
... 延时主要取决于解析视频的处理算法
François Daoust (W3C): 我刚才提到的encoding/decoding API是否能解决这个问题？
银国徽（字节跳动）： 我们要求浏览器开放FFMPEG接口确实是需要编解码能力
François Daoust (W3C): 你们需要的是否是浏览器开放所有编解码器？浏览器厂商不支持某些编解码器是有商业原因，而不是技术原因的
王天笑（知乎）： seek会造成视频浪费，和Chrome的策略不一样
... 如何平衡预缓冲和流量节省？
银国徽（字节跳动）： 播放器会暴露preload time接口，由播放器使用者自行决定。
... 实践经验是设置5s已经足够了，比起Chrome一直下载，会更好一些
黄之昊（bilibili）： 西瓜视频播放的质量通过哪些指标衡量？
银国徽（字节跳动）： 公司有统一的体验标准指标，Web和端都是一样的
... 不方便透露太多，可私下交流
@@: 如何解决音画不同步？
银国徽（字节跳动）： 解决方案是把音频和视频放在一个sourceBuffer
陆禹淳（声网）： 服务端是传统的视频存储的吗？处理都在前端吗？
银国徽（字节跳动）： 需要综合衡量，根据场景来判断是需要服务端做还是前端做？
陆禹淳（声网）： 会对传输进行优化吗？
银国徽（字节跳动）： 会
@@: 音频和视频类型MIME对象不一样能放到同一个sourceBuffer吗？
... 视频的处理是不是所有场景下都适用？
银国徽（字节跳动）： 对于短视频（低于30分钟）测试过，算法是很快的，100ms以内。长视频下算法还要优化。
... 对象不一样可能解码会失败
@@: 为什么需要逆向来判断另一个文件的IM？
银国徽（字节跳动）： 解析Mdat时候并不知道具体IM是什么，需要逆向推导...
王成（知乎）： 想详细了解之前说的标准提议的第一个点
银国徽（字节跳动）： 以视频上传为例，可以在浏览器里通过播放器来进行视频上传需要的视频处理工作。
王成（知乎）： 在hybrid app中有没有应用？
... 如何判断使用native app还是Web？
银国徽（字节跳动）： 通过场景来看，hybrid也可以调用native app来播放
陶清乾（百度）： 我是来自百度的陶清乾，Web中文兴趣组的联合主席
... 大家如果还有哪些问题、期待和建议，可以畅所欲言
黄之昊（bilibili）： 大家都参与和视频相关的工作，如何衡量视频质量？
... 在bilibili，我们关注起播速度、卡顿率和播放速度
... 我认为现有浏览器提供的信息是不够的，希望浏览器提供更多的性能相关的信息
王天笑（知乎）： 我们目前主要对播放次数、首帧时长、缓冲时长、播放失败率、重播次数等进行打点
... 如果视频的加载市场超过数十秒，我们也会认为播放是失败的，会进行打点
王成（知乎）： 在实现seek缓冲时长打点时，我发现浏览器在这方面的实现是不一致的
胡皓（腾讯）： 除了网络问题，机器配置也可能导致丢帧
... 我们会计算丢帧率
诸剑俊（英特尔）： 我们进行视频质量分析时，会对比不同codec的实际表现
陶清乾（百度）： 如何衡量视频体验是一个很重要的问题，我觉得可以输出到标准里去
... 现在在native app和浏览器里看视频是很不一样的
... 取决于浏览器和视频播放器提供的能力
... 刚才主要提到了PC端，大家在移动端上对播放器有哪些期待？
王成（知乎）： 我觉得移动端目前比较大的一个痛点是不同手机全屏的体验差别比较大，即使是在hybrid app里也是一样
... 可能需要推动浏览器统一实现
姚穗斌（腾讯）： 我补充一下
... 在全屏之后，整个UI已经被系统接管了，开发者无法进行定制，这个体验不够好，是HTML5体验不够好的一个地方
... 改进方法可以参考微信小程序
杨刚（百度）： 元素全屏是可以定制UI的，虽然浏览器支持不够统一
... 我觉得在不久的将来，在这方面达成统一是没问题的
王石成（小米）： 浏览器的问题有两个方面
... 从前端来说，不仅仅是全屏，inline也是有问题的，同样也被浏览器接管
... 关于全屏，各家浏览器的实现也不一样
@@: 有的浏览器劫持视频是为了给自己做广告……
陶清乾（百度）： 这个已经超出了标准讨论的范围了
黄之昊（bilibili）： 我们和很多厂商沟通过，推动起来比较困难
... 很希望浏览器厂商提供一个开关让开发者选择使用浏览器的播放器还是使用自己的播放器
@@: 即使是同一个浏览器内核，在不同手机上渲染还是会有区别
俞天翔（快手）： 想问W3C这边，对于原生支持H.265的推进是否有过协商？
François Daoust (W3C): 问题是专利，W3C的标准是RF的，无法规定浏览器厂商必须支持某个含有专利的codec
... 过去我们讨论过AV1，AV1是RF的，这也许是一个方向
... Media Playback Quality是W3C已经在讨论的一个标准，曾经是MSE的一部分，现在在WICG孵化，并且可能进入新的Media WG
... 另一个标准是Media Capabilities
... 这个标准暴露了设备特定的编解码器是否可以解码一个给定的分辨率、码率或帧率，播放是否流畅和省电等很多数据
... 如果大家对获取视频质量数据有好的建议，新的工作组欢迎大家的反馈！
陶清乾（百度）： 中文兴趣组也欢迎大家的反馈，将来我们也可以反馈到对的工作组和对的人上
... 最后是关于W3C中文兴趣组下一个活动的预告
... 我们计划在4月下旬或5月上旬举办一个小程序相关的活动，希望大家能参加
... 时间和地点会在近两周确定下来，欢迎大家关注！
贾雪远（W3C）： 今天的会议纪要欢迎大家的改进，整理后将与公众分享，有任何问题欢迎联系我们！