在 WebRTC 会议的背景下，虚拟媒体流是指由选择性转发单元 (SFU) 生成的媒体流，用于汇总和分发来自多位参与者的媒体。与直接点对点媒体流（会在大型会议中创建复杂的网状连接）不同，虚拟媒体流可简化拓扑。SFU 会接收每位参与者的各个媒体流，并有选择地将活跃或相关的媒体流转发给其他参与者，将这些媒体流多路复用到一组较小的固定传出虚拟媒体流中。
此方法可减少每位参与者需要同时处理的传入流数量，从而降低处理和带宽要求。每个虚拟流一次只能包含一位参与者的媒体，SFU 会根据发言者活动或视频分配等因素动态调整虚拟流。参与者会收到这些虚拟流，从而有效地看到会议的合成视图，而无需管理来自其他每位参与者的各个流。虚拟媒体流提供的这种抽象对于将 WebRTC 会议扩展到大量参与者至关重要。
为了接收音频，客户端必须提供正好三个音频媒体说明，从而创建三个本地音频收发器。如需接收视频，客户端必须提供一到三个视频媒体说明，以确定视频收发器的数量。
接收器
每个客户端自有收发器都有一个专用 RtpReceiver 和一个专用“媒体轨道”，用于接收来自 Meet 服务器的音频 RTP 流。
每个轨道都有一个唯一的 ID，并从特定媒体源接收自己的不同 RTP 数据包流。例如，轨道 A 可能从 production-1 接收音频，而轨道 B 从 production-2 接收音频。
SSRC
每个 RTP 数据包都有一个同步源 (SSRC) 标头值，用于将其与特定轨道相关联。
通过 Meet Media API 进行的音频会话使用三个不同的媒体流，每个媒体流都有自己的静态 SSRC。一旦建立，这些 SSRC 值在会话的整个生命周期内都不会改变。
虚拟流
Meet Media API 使用虚拟媒体流。这些值在整个会话期间保持不变，但数据包的来源可能会发生变化，以反映最相关的 Feed。虚拟媒体流在音频和视频方面的行为方式相同。
RTP 数据包标头中的贡献源 (CSRC) 用于标识 RTP 数据包的真实来源。当参与者加入会议时，Meet 会为每位参与者分配各自唯一的 CSRC。此值在用户离开之前保持不变。
由于 SSRCs 的数量在整个 Meet Media API 会话中保持不变，因此存在以下三种可能的情况：
参与者人数超过了可用的 SSRC 数量：
Meet 会传输三个 SSRC 中声音最大的三个人。由于每个 RTP 流都有自己的专用 SSRC，因此流之间不会混杂。
图 1. Meet 会在三个 SSRC 中传输声音最大的三个人。 如果会议中的任何原始音频流不再是最响亮的音频流，Meet 会将构成 SSRC 的 RTP 数据包切换到最响亮的音频流。
图 2. Meet 会将 RTP 数据包切换到新的声音最大的人。 活跃参与者的数量少于三个音频 SSRC：
如果会议中可用的 SSRC 比音频流多，Meet 会将所有可用的音频数据包映射到其自己的唯一 SSRC。任何未使用的 SSRC 仍处于就绪状态且可用，但不会传输任何 RTP 数据包。
图 3. 将可用的音频数据包映射到其自己的唯一 SSRC。 活跃参与者数量等于三个音频 SSRC：
如果参与者数量相等且有可用的 SSRC，则每个参与者的媒体都会映射到专用的 SSRC。只要此特定场景持续存在，这些映射就会一直存在。
图 4. Meet 会将每位参与者的媒体内容映射到专用的 SSRC。