多视角视频市场格局：流媒体架构如何决定成败

Multiview（多视角）即在同一屏幕上同时观看两路、三路或四路直播信号，正在成为体育直播中的核心能力。决定 Multiview 成败的关键并不只是“是否支持多画面”，而是采用怎样的交付架构。对于大多数内容平台而言，除了 YouTube 等大型公司会自研 Multiview 技术之外，更多平台会在 Skreens、Broadpeak、Synamedia、Tiledmedia 等供应商之间选择。它们分别代表了服务端合成、客户端合成和打包器侧合成等不同路线，而不同路线在设备兼容性、个性化能力、带宽成本、广告集成、同步延迟和实施复杂度上都有明显差异。

文章来源: Streaming Media, Featured Articles
原文题目: Multiview’s Vendor Landscape: How Streaming Architectures Determine Success
原文作者: Jan Ozer
原文链接:   https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Multiviews-Vendor-Landscape-How-Streaming-Architectures-Determine-Success-175414.aspx

引言

Multiview 的基本目标，是让观众在一个屏幕中同时观看多个直播信号。例如体育赛事中，用户可以同时关注多场比赛、多路摄像机或不同节目源。文章指出，Multiview 已经不再只是一个新奇功能，而是逐渐成为体育流媒体服务中的关键能力。

不过，真正影响 Multiview 体验和成本的，并不是多画面本身，而是背后的流媒体架构。不同架构决定了多画面在哪里生成、由谁负责解码和同步、是否需要新增云端编码资源、能覆盖哪些终端设备，以及是否能够支持用户自定义组合。

文章将主流方案分为三类：第一类是以 Skreens 为代表的服务端 Multiview；第二类是以 Tiledmedia 为代表的客户端 Multiview；第三类是以 Broadpeak 和 Synamedia 为代表的打包器侧 Multiview。下面分别介绍三种方案的工作方式和适用场景。

架构一：服务端 Multiview（Skreens）

在服务端架构中，各个直播信号会像普通频道一样先被编码成 ABR 码率阶梯。随后，当平台定义好某个 Multiview 布局后，这些组成频道会被送入云端合成引擎，由合成引擎按照指定布局合成为一路新的视频。

合成后的 Multiview 视频会被重新编码为一套路新的 ABR 阶梯。对于 origin、packager 和播放器来说，它看起来就像一个普通直播频道。用户端只需要解码一路视频，因此这种方案几乎兼容所有能够播放现有直播频道的机顶盒、智能电视和 CTV 设备。

这种方式的最大优势是兼容性强，特别适合拥有大量旧设备用户的运营商。平台可以在不改播放器的情况下上线 Multiview，也不用担心低性能设备是否能够同时解码多路视频。代价则是云端基础设施成本较高：每一种固定布局，或者每一种用户自定义组合，本质上都可能需要成为一路新的实时合成频道，并在云端进行渲染和编码。

Skreens 以 Tessera 品牌提供服务端 Multiview 方案。文章还提到，MediaKind 的 MK.IO Multiview 底层也使用了 Skreens 技术，并已被 Comcast 部署为 Xfinity Multiview，用于 X1 和 Xfinity Stream。2026 年 4 月，Skreens 还宣布将支持 FOX Sports 和 FOX One 在部分大型直播活动中的策划式多画面呈现。

架构二：客户端 Multiview（Tiledmedia）

在客户端 Multiview 中，云端不会预先合成多画面。CDN 只负责分发 Feed A、Feed B、Feed C、Feed D 等普通 HLS 或 DASH 直播流，播放器则在客户端同时打开多个连接，分别拉取多路视频，并在本地完成 ABR 控制、帧级同步和画面合成。

这种方式的主要优势是灵活性。因为没有服务端合成，平台不必为每一种布局启动新的云端编码器。理论上，它可以支持任意输入组合和任意画面布局，特别适合用户自定义 Multiview 的场景。

缺点是计算压力被转移到了终端设备。早期一些商业实现会同时运行多个独立播放器实例，每个实例都有自己的 ABR 和解码管线。这种方式很容易触及普通智能电视或低端流媒体盒子的 CPU、GPU 和内存限制。Tiledmedia 代表的是一种更专门化的客户端方案：由一个专门播放器负责多路拉流、合成、同步和展示，而不是简单并行运行多个完整播放器。

文章特别指出，客户端 Multiview 有一个细微但重要的体验优势：音频焦点切换更快。因为播放器本地管理多路解码器，当用户把主音频从一个画面切换到另一个画面时，可以立即完成，不需要修改 manifest，也不需要额外缓冲。相比之下，服务端和打包器侧方案在切换音频时往往涉及 track 或 rendition 切换，可能会带来轻微但可感知的卡顿。

除了 Tiledmedia 之外，一些商业播放器 SDK 也开始提供 Multiview 能力。例如 Dolby OptiView SDK 暴露了 MultiViewPlayer，Bitmovin Player SDK 也在 iOS、tvOS 和 visionOS 上支持最多五个播放器实例。不过，文章强调，这类方案更像是播放器功能，而 Tiledmedia、Skreens、Broadpeak 和 Synamedia 则是面向 Multiview 的系统级方案。

架构三：打包器侧 Multiview（Broadpeak / Synamedia）

打包器侧 Multiview 介于服务端合成和客户端合成之间。所有直播摄像机或节目源首先被编码为常规 ABR 阶梯，而 Multiview 的构建发生在 packager/origin 层，而不是云端视频合成器或重客户端中。

这一方案的关键组件是一个 Multiview layout service。它接收来自应用端的布局选择，并将这些选择转换成元数据参数：哪些输入流应该出现在每个 tile 中、每个 tile 的尺寸是多少、应该放在屏幕什么位置。这些指令会发送给 packager，由 packager 利用 manifest 操作和 tiling 逻辑，从已有输入码率阶梯中组装出一个“虚拟”的 Multiview 频道。

通过 CDN 传输的是一路 tiled bitstream，并配有常规 HLS 或 DASH manifest。为了实现这种方式，单个频道需要使用 HEVC 或 VVC，并保持一致的 tiling 方案和运动约束。只要 tile-aware encodes 已经准备好，Multiview packager 就可以在压缩域中选择和聚合 tile，并通过轻量的 header rewriting 生成多画面输出，使任何支持 HEVC 的解码器都可以把它当作一路视频渲染。

从运营商角度看，这种架构把 Multiview 从一个转码项目变成了一个增量的打包问题。每个输入频道仍然只需编码一次，而 Multiview layout service 和 origin 能够通过更新 manifest 和 tile map，将这些已编码片段重新组合成不同的 Multiview 变体。

文章提到，Broadpeak 和 Synamedia 是这一类方案的代表。Broadpeak 将其实现称为 Multiview，并采用“multi-package”架构，是其 origin packaging 和 cloud DVR 技术的扩展。Synamedia 的方案建立在 Quortex cloud video platform 之上。不过截至 2026 年 6 月，Synamedia 的 Video Network 业务，包括 Quortex，正在被 Lumine Group 收购，因此相关 Multiview 技术栈后续可能会归入 Lumine 旗下的 Quortex 品牌。

如何选择架构

文章认为，Multiview 架构选择需要从多个维度综合判断，包括处理位置、设备覆盖、个性化成本、传输带宽、广告集成、同步和延迟等。表 1 对三类方案进行了概括：Skreens 代表服务端合成，Tiledmedia 代表客户端合成，Broadpeak/Synamedia 代表打包器侧合成。

设备兼容性

在兼容性方面，服务端方案最强。因为它最终输出的是一路普通直播流，所以任何能播放现有频道的设备都能播放 Multiview。打包器侧方案也接近服务端方案，只要设备支持 HEVC tiled stream 解码，就不需要对播放器做太多特殊改造。

客户端方案的兼容性相对受限。许多智能电视和低端 dongle 同时只能可靠解码一路或两路视频，因此真正稳定的客户端 Multiview 往往更适合高端 CTV 设备和 Apple TV 这类性能更强的盒子。

从固定 Multiview 到 BYOMV

早期 Multiview 往往是固定布局，也就是所有观众看到相同的多画面频道，最多只能切换不同频道。近年来，行业趋势正在转向个性化，由此出现了 BYOMV（Build Your Own Multiview）的说法。YouTube TV、Sunday Ticket、ESPN、Peacock 等服务已经允许观众选择哪些比赛或摄像机出现在不同窗口中。

文章指出，三种架构都可以实现用户级灵活性，真正的问题在于大规模提供这种个性化需要付出多少成本。

个性化成本

在服务端方案中，每个独特的 Multiview 频道都需要自己的实时合成编码。如果要为几十万用户提供完全个性化的 BYOMV，成本会迅速上升。因此实际部署中，服务往往会限制 Multiview 频道数量，并让有相似选择的用户共享同一个多画面频道。

客户端方案没有额外编码成本。平台只需要提供各个独立直播流，由播放器在本地拉取和合成。打包器侧方案则介于二者之间：每个频道只编码一次，packager 通过 remix tiles 和更新 manifest 生成不同组合，避免为每个布局单独转码。其主要增量成本在于 packager 复杂度，通常低于服务端多路编码，但高于纯客户端方案。

带宽成本

在带宽方面，服务端 Multiview 像普通单频道一样工作。无论用户看一场比赛还是四场比赛，传输码率都接近一个普通 HD/4K 频道。

客户端方案内部差异较大。如果是“多个播放器实例”的实现，每个 tile 可能都会认为自己在全屏播放，并拉取最高 4K 档位，然后再缩小显示。这种情况下，四画面布局最坏可能接近 4 路 4K 带宽。Tiledmedia 的单播放器方案则会根据每个 tile 实际显示像素选择相应码率。例如在 4K 屏幕上的四画面布局中，每个四分之一屏 tile 大约拉取 1080p 档位。四路 1080p 通常不如一路 4K 高效，但差距不会达到 4 倍。

打包器侧方案原则上类似 Tiledmedia，只是这种选择和组合发生在 origin 端，而不是播放器端。它的带宽效率通常不如服务端合成，但也远低于简单的 4 路全码率客户端拉流。

广告集成

服务端方案在广告集成上最简单。因为合成器输出的是一路普通直播频道，它可以直接接入现有 DAI 工作流，不需要新的广告技术集成。缺点是，如果多个用户共享同一个 Multiview 频道，他们看到的 stitched ad 通常也是相同的；若要做到逐用户个性化广告，则理论上需要为每个用户输出专属编码。

客户端方案则可以通过另一种方式实现真正的逐用户广告个性化。Tiledmedia 的模式是把广告作为 Multiview 布局中的一个 tile，例如画中画、并排窗口或其他配置。这样观众不会离开 Multiview 体验，同时可以实现家庭级或用户画像级广告投放。代价是广告决策发生在播放器端，需要在客户端接入广告请求、曝光跟踪和频控等逻辑。

打包器侧方案更接近传统 DAI，但也有扩展空间。由于每一种 Multiview 组合都可以被组装成独立 rendition，它可以作为单独广告库存注册到 DAI 系统中。文章还提到，当视频合成器能够控制布局时，还可以产生新的广告形式，例如传统 L 型 banner 中通常是缩小视频并填充静态图片，而 Multiview 中对应空间则可以承载一路直播视频。

同步和延迟

同步与延迟是三种架构在日常运营中差异最明显的地方。服务端和打包器侧方案都会在编码和打包前对齐所有输入流，然后交付一路同步视频。因此 LL-HLS 或 LL-DASH 的工作方式与普通单场比赛类似：一个 manifest、一个 buffer、一个 live edge。

客户端方案则需要同时处理多个 live manifest 和多个 buffer，在低延迟下保持严格帧级同步更困难。不过，它在交互体验上有优势，例如切换音频焦点或调整布局时，许多操作可以完全在播放器本地完成，因此响应更快。

集成复杂度

从实施角度看，服务端 Multiview 主要是后端工程。平台需要部署合成器和编码器集群，将它们接入已有 encoder、origin 和控制平面，并把生成的 Multiview 频道暴露到内容目录中。客户端可以继续使用现有播放器，只需要在 UI 中添加动态 Multiview 频道入口。

客户端 Multiview 则主要是播放器和应用工程。它复用现有各路直播码率阶梯，但应用需要知道应该打开哪些 feed，需要具备同步多路流的逻辑，并且设备需要有足够能力同时解码和合成多路视频。相比之下，编码器和 origin 栈变化较小。

打包器侧 Multiview 位于 origin 或 packager 层。每个频道仍然只编码一次，由 Multiview service 在打包阶段组装组合。集成工作包括启用 tile-aware packaging、部署 Multiview 控制服务，并确保播放器能够解码 HEVC 并理解布局元数据。整体来看，客户端改动通常小于完全客户端方案，但 packager 层需要具备更强能力。

总结

文章最后强调，Multiview 不是一个可以简单“加上去”的功能，而是一个架构决策。它决定了平台能够覆盖哪些设备、规模化运营需要多少成本，以及产品团队能够给用户多少体验控制权。

服务端、客户端和打包器侧三种方案分别代表了不同取舍。服务端方案兼容性最好、广告集成最自然，但个性化和云端成本压力较大；客户端方案最灵活，适合 BYOMV 和快速交互，但对播放器和终端性能要求高；打包器侧方案试图在二者之间取得平衡，通过 HEVC/VVC tiling 和 manifest 级 remix 避免为每个布局重新编码，同时保持较好的设备兼容性。

因此，选择哪种 Multiview 架构，取决于服务的设备覆盖范围、个性化需求、现有基础设施和成本模型。对于流媒体平台而言，正确的问题不是“是否要做 Multiview”，而是“应该在哪里生成 Multiview，以及为此愿意承担怎样的成本和复杂度”。