模式选择
接下来的篇幅会比较长,如果您不在意不同模式实现的细节,您可以直接在页面下方找到不同场景的推荐模式。
在一个简单音视频通话的场景中,视频画面一般和发布这个视频画面的用户是一个一对一的关系,即一个用户发布一路流,其他用户订阅这个用户就等于订阅他发布的那一路流。
但是在某些特殊的业务场景中,是希望可以打破这个一对一关系的。一个用户应该可以发布多路不一样的流(比如来自不同的摄像头、屏幕、窗口等等),而用户在订阅他的时候也可以动态选择到底要订阅他的哪些流。在这种场景下,房间的用户和房间中用户发布的流就变成了一对多的关系,即每个用户都可以发布多路音视频流。
七牛实时音视频云 SDK 从 2.0.0
版本起正式支持了这个一个用户对应多路流的需求,但是在这种一对多的场景下,我们不再将这些音视频画面称之为流,在之后的叙述和介绍中,我们都会用 Track(音视频轨道) 这个词。
如果您对音视频开发有一定的了解可能会知道,Stream(流) 是由 Track(轨道) 组成的。默认情况下,一路 Stream 只会包含一个音频 Track 和一个视频 Track。在 2.0.0
后,我们取消了这个默认假设,一个 Stream 可以由任意多个 Track 来组成,并把用户可以操作的最小单元改为 Track, 以此来实现了这个一对多的对应关系。
如果您是正在使用我们
2.0.0
以下版本的老客户,可能会考虑这种对应关系的变化要如何向下兼容的问题。其实我们的解决思路很简单,在一个用户所有发布的 Track 中,会有一个属性叫做master
,我们只允许一个用户发布至多一个 video master Track 和至多一个 audio master Track。master 属性为true
的 Track 会被自动组合在一起映射成之前版本中的流
那么为什么要有模式选择呢?因为从上层开发的角度来看,这样的对应关系是两面性的。一方面,整个连麦过程可以控制地更加灵活、更加细致。但另一方面,额外的对应关系给开发带来了不小的接入成本。
所以在这里,Web 端选择封装了两套模式的 API 供用户选择。一套我们称之为 Stream 模式
,也就是用户和流一对一关系的模式。一套我们称之为 Track 模式
,也就是用户和 Track 一对多关系的模式。需要注意的是,这 2 个模式只有在 Web SDK 下 的 API 中有区别,在实际实现上,都是通过刚刚描述的以 Track 为单位操作流实现的。只是在 Stream 模式
下,我们只允许用户发布至多一个音频 Track 和至多一个视频 Track
master
属性的细节
关于 上文中提到,一个用户至多只能发布一个音频 master
Track 和一个视频 master
Track。这些 master
Track 就会被映射成一个 Stream
来兼容一个用户只能发一路流的版本(小于 2.0.0
,或者使用 Stream 模式
)。所以,对于这些版本来说,他们是感知不到房间其他非 master
Track 的信息的,想要和这些版本互通,一定要注意发布的 Track 是否是 master
。
在 Track
模式下,所有 Track 的 master
默认都是 false
,但是允许用户自定义设置 master
属性。在 Stream
模式来下,不用过多的理解 Track 的概念,只要当作一个用户只能发一路流(这一路流是由最多 2 个 master
Track 组成)就好了,如果这个房间中有用户发布了多路流,Stream
模式也只能感知到 master
Track 所组成的那一路流。
如果您需要使用 Stream 模式和 Android/iOS/Windows 互通,一定要注意其他端发布 Track 的
master
是否为true
。
Track 模式设置
master
属性可以参考 API 文档
什么情况下使用 Track 模式
当您的需求场景满足以下情况时,优先使用 Track 模式:
- 不清楚需求边界的情况
- 需要一个用户同时发布多路视频画面或者多路音频画面
- 用户订阅时需要有动态订阅的逻辑,即纯音频订阅或者纯视频订阅等等
- 虽然同一时刻只有一个视频画面,但是有画面切换的需求
什么情况下使用 Stream 模式
当您的需求场景满足以下情况时,优先使用 Stream 模式:
- 明确需求中一个用户最多只会发布一路视频和一路音频
- 没有动态订阅的需求,远端用户发布什么就订阅什么
- 是老版本用户希望升级到 v2
如果您是使用 Web
2.0.0
以下的老客户,希望升级到2.0.0
,请阅读这篇老客户升级指南