Skip to content

Latest commit

 

History

History
87 lines (32 loc) · 6.99 KB

FAQ.zh.md

File metadata and controls

87 lines (32 loc) · 6.99 KB

FAQ


Q1:为什么弹幕不能使用JS来实现或者使用TTML或WebVTT来扩展?

A1:弹幕目前主流的实现方式是使用Canvas或者DOM+CSS+JS来实现,但是实现弹幕的效果对于开发者来说成本很大,开发复杂成本高,所以希望能通过标准化使得开发实现简化并能够在不同的厂商中弹幕的格式和实现方式保持一致。

弹幕可以参考 WebVTT 对文本的设计,但弹幕的信息密度、使用区域、使用方式和 WebVTT 有很大不同,像直播弹幕、弹幕上墙、页面互动、非文字弹幕等用例。此外,弹幕对于内容的自定义程度更高,允许直接定义 CSS 样式和 emoji、图片、超链接等内容。

目前TTML/WebVTT对于弹幕的需求还无法满足,具体可以参考:这里

Q2:弹幕显示在视频画面上会造成遮挡,是否会阻碍观看视频,降低观看体验?

A2:传统的播放器评论系统是独立于播放器之外的,因此评论的内容大多围绕在整个视频上。 但是弹幕但是其只会在视频中特定的一个时间点出现,因此在相同时刻发送的弹幕基本上也具有相同的主题。弹幕的喜爱者多以80后、90后、00后年轻人为主,这代年轻人大多是独生子女,看视频本身是孤独的娱乐项目,在参与评论时就会有与其他观众同时评论的感觉,找到更多的共鸣感。

此外,还可以通过降低透明度、控制弹幕区域、文字大小等方式根据个人合适的习惯调整到最佳的观看效果。同时也可以通过选择是否显示弹幕开关来控制弹幕的显示与不显示。

Q3:弹幕不依附<video>使用,会不会造成弹幕内容管理复杂化?

A3:弹幕规范描述的是弹幕绘制方式,可以看做把弹幕的渲染标准化了,不包括放在弹幕层上内容管理的标准化。插入时机和还是保持原先的逻辑,不会更复杂。

由于弹幕不依赖于<video>,因此不要求有弹幕列表。在常见的点播视频弹幕场景中,往往有一个类似 WebVTT 这样同步视频时间轴的弹幕列表, 这种情况需要由开发者根据视频时间添加 bulletchat,类似也应当由使用方来管理内容,或通过 bulletchatlist 中的 bulletchat 元素来获得当前列表。

Q4:当前文档中描述“如果弹幕区域和渲染的列表固定不变,那么每次渲染每条弹幕所出现的位置和顺序都是固定的”,这可能会导致性能问题吗?

A4:allowOverlap 允许弹幕重叠的确会带来更多的计算,目前 B 站所用的算法从头开始算的时间复杂度是O(n^2),不会带来太大的消耗,目前的弹幕也是这样实现的。

弹幕插入的时机由外部决定,因此弹幕区域只关心对插入的弹幕按这样的规则展示,不会去计算外部列表。列出弹幕渲染的确定性是为了说明弹幕是按固定规则添加和不具有随机性这样的特性。

Q5:如草案所述,有 4 种模式的 bulletchat 元素。 当 allowOverlap 设置为 false 时,是否可以将不同模式弹幕堆叠起来?

A5:每种弹幕模式可以看作不同的虚拟层,allowOverlap是控制不同模式自身是否允许重叠,因此无论是否有设置allowOverlap,不同模式的弹幕都允许堆叠。

Q6:play-state, duration, delay 是草案中列出的三种样式属性, 为什么它们是样式而不是属性?

A6:可以把弹幕元素理解为加了一种动画的效果,并且弹幕不一定是和<video>强关联的,所以目前我们认为使用样式的方式更优一点,可参考CSS animation。

Q7:弹幕和评论有什么区别?

A7:评论是一种脱离视频时间轴之外存在的对于视频内容的讨论,一般评论的展示方式为在视频播放的下方,用户想看关于当前视频播放帧的评论需要暂停视频后查看,而弹幕是一种与视频时间轴关联的讨论方式,当前展现的弹幕和当前视频内容存在关联,对于用户会收获更多的视频外的内容和启发。

另外,对于非视频类的场景中,弹幕的展现方式更加的丰富和交互体验,相比较评论就比较传统和单一。

Q8:弹幕的不同模式是为了满足什么不同的需求?

A8:一般滚动弹幕是常用模式,默认也都是滚动弹幕模式来展现弹幕的内容,但有时为了突出显示不同的内容,用户可以选择逆反弹幕、顶部和底部弹幕来展示弹幕的内容,相比较大部分的滚动弹幕,这几种不同的模式可以突出显示弹幕内容,满足特立独行和张扬个性的用户的需求。

Q9:服务器传到客户端的信息,有多少是渲染呈现信息(如:描述弹幕的绘制区域、大小、颜色、滚动方式等信息)?

A9:在客户端用户发送弹幕到服务端时主要包含以下信息:弹幕内容、发送弹幕对应的视频时间轴的时间、弹幕发送时间、弹幕的字体大小、字体颜色、弹幕显示模式、弹幕发送者信息等。所以从服务端传到客户端用户显示的弹幕信息也应该包含同等的信息或者更多的信息,比如除了上面列举的外,可能还包括:延迟时间、显示生命时间等信息。除了弹幕内容信息外,其他的信息都可以理解为是渲染呈现相关的信息。

Q10:弹幕扩展到沉浸式场景(AR/VR)以及多端中的可能?

A10:弹幕标准化工作中考虑以TTML为基础使用简单轻量的文件格式(非XML文件格式),希望能够支持文件和实时弹幕的功能的话,可以制定一个针对弹幕的跨平台和使用场景的标准,标准包含弹幕在web中的实现方式以及在不同平台(如:电视端、电影大屏等)和更多场景中的弹幕文件交换格式等,这个标准可以结合其他的技术(如XR、WebRTC等技术)来扩展到不同的更多的场景中。

Q11:如果定义弹幕元素,有多大的WebAPP规模会使用他呢?

A11:就像规范文档中弹幕规模列举的已经支持弹幕的厂商的用户规模,并且在中国新兴的小程序中也有弹幕的使用案例,在某些支持评论的社交平台上也支持弹幕的方式来发送评论,所以如弹幕的优势分析中描述,未来年轻人会接受和喜欢使用弹幕,弹幕会越来越广泛,相信会有大规模的开发者会使用。

Q12:弹幕想要在W3C中标准化的内容是什么或方向是什么?

A12:弹幕的规范,推荐的API中所述,弹幕想要标准化的是规范弹幕的实现方式,是一种HTML元素,元素包含:弹幕展示的样式、位置、时间、内容格式等属性和事件。