世界杯正在如火如荼地进行着，精彩的镜头每天都在上演。细心的你可能已经留意到，本届世界杯不只是比赛精彩，屏幕上的”看法”也在悄悄变化。

　　你可能已经在看球时见过这种画面：电视屏幕被分成几块，左上角是主摄全景，右上角是球门后方特写，下面还有战术俯瞰和裁判视角——所有画面同时播放，不用你手动切换。这就是 Multiview（多画面）。

　　这个功能听起来不复杂，但它正在成为体育流媒体的核心能力之一。对观众来说，这意味着你可以在一块电视屏幕上同时盯着四场 NBA 季后赛，或者在世界杯直播中同时看到主摄全景、球门后方特写、战术俯瞰和裁判第一视角，而无需手动切换。对流媒体平台来说，这已经不再是锦上添花的”加分项”，而是留住体育订阅用户的基础设施——YouTube TV、ESPN、Peacock 都已经把多画面视为核心竞争力。

　　但真正关键的差别不在于”有没有这个按钮”，而在于背后的技术架构——它决定了画面流不流畅、你能不能自由选择想看的机位，以及平台要为此花多少钱。

　　但同样是多画面，不同平台的实现方式差别很大。目前行业里主要有三种技术路线，那么这三种路线分别是什么？我们不妨用大家比较好理解的做菜来打个比方：

　　1、服务端多画面：后厨直接把四道菜摆好盘，做成一道拼盘端给你。你拿到的就是一条拼好的视频流，任何设备都能直接播。代价是你想换个布局或换一路信号，后厨就得重新做一盘。每种组合都是一条独立的编码流水线，规模一大，云端账单很难看。

　　2、客户端多画面：四道菜分别端上桌，你自己决定怎么摆。每路直播流都是完整编码好的成品，播放器在本地完成拼接和布局，想怎么排随时改，灵活度拉满。代价是你的桌子得够大——同时解码四路流很吃设备性能，低端电视和流媒体棒经常扛不住。

　　3、打包端多画面：后厨把四道菜分别做好，但在传菜窗口由传菜员按你点的组合重新码盘。每道菜只烧一次，不用为每种摆法重开一口灶；传菜员只做轻量级的拼装，成本远低于重新烧一遍。端到桌上还是一份拼盘，普通盘子就能装。

　　一句话收尾：服务端是”后厨做好拼盘端上桌”，客户端是”成品菜分开上、自己需要费心摆弄”，打包端是”传菜窗口现拼”。三条路分别在设备兼容性、灵活性和成本效率上各有侧重——这就是选型的根本取舍。

　　接下来，我们就从这三条路线出发，逐一拆解它们的工作原理和优劣。别担心，我会尽量少说”黑话”——实在绕不开的术语，我会随手解释。

　　除了 YouTube 这样少数有能力自研多画面技术的大厂之外，大部分视频服务商都会在少数几家供应商中做选择，包括 Skreens、Broadpeak、Synamedia 和 Tiledmedia。它们各自代表了不同的架构路径：服务端多画面、打包端多画面，以及播放器端多画面。

　　YouTube 自主研发的多视图功能集，为体育赛事观看提供了标准

　　让我们先快速梳理一下这几种架构，以及背后对应的产品与厂商，然后再看在做技术选型时，运营方应该重点评估哪些关键维度。

　　本文基于 Jan Ozer 的文章进行的深度分析和编译整理。Jan 是流媒体行业最受认可的技术专家之一，现任 Streaming Media Magazine 特约编辑，专注于编解码器评测、云编码器基准测试和 QoE 监测工具评估。他长期与流媒体平台和视频技术厂商合作，提供编码流水线验证、码率梯度优化和画质指标测试等服务，同时也是一位高产的技术教育者——著有 20 余本专业书籍，开设了 10 余门在线课程，通过 Streaming Learning Center 培训了数千名从业者。

　　架构一：服务端多画面（Server-Side Multiview）

　　服务端多画面，本质上就是前面说的”后厨做好拼盘端上桌”。具体来说：平台先把每一路直播画面（比如 A 球场、B 球场）分别录好，然后在云端服务器上，由一个叫做”合成器（Compositing Engine）”的软件模块，像拼图一样把它们按指定布局（比如四宫格）拼成一整张画面，输出为一条完整的视频流。

　　在服务器端的多视图模式中，服务组件会整合并编码多视图内容，然后像处理其他频道一样，将处理后的内容作为单一数据流发送给播放器

　　拼好之后，合成器还会对这张”拼盘画面”重新压缩，生成高清、标清等不同画质版本（也就是业内说的 ABR 码率梯度，简单理解就是“同一个视频准备了从高清到省流量的多个版本，播放器根据你的网速自动选合适的那个”）。对于后续的分发系统来说，这条拼好的视频流和一场普通直播没有任何区别。

　　这意味着什么？你家的智能电视、机顶盒，哪怕是入门级的流媒体棒，只要能看普通直播，就一定能播这种多画面——因为对播放器来说，它根本不知道自己在播的是一个四宫格，它只当这是一条普通的视频流。

　　所以对于那些拥有大量用户、设备五花八门的运营商来说（比如有线电视公司），服务端方案特别有吸引力，它不用升级用户手里的设备，也不用担心老旧的硬件带不动。

　　但代价也很明显：这种”拼盘”是在云端做的，每多一种画面组合，就要多开一条云端流水线。打个比方，如果观众想在四宫格里自由选择想看哪四场比赛，那么理论上每种排列组合都需要后厨单独做一份拼盘。你可以想象，这个账单会有多恐怖。

　　Skreens 旗下的品牌 Tessera 提供服务端多画面方案。除了直销给视频服务商之外，Skreens 也是 MediaKind MK.IO 多画面方案背后的技术提供方，而 MK.IO 已被 Comcast 部署为 X1 与 Xfinity Stream 上的“Xfinity Multiview”。2026 年 4 月，Skreens 宣布达成一项协议，将部署 Tessera 软件平台，用于“为部分重大直播赛事提供精心策划的多画面呈现，包括本届由 FOX Sports 呈现、在 FOX One 上流媒体播放的 FIFA 世界杯”。

　　架构二：客户端多画面（Client-Side Multiview）

　　客户端多画面，就是前面说的”四道菜分别端上桌，你自己摆”。云端不做任何拼接工作，而是把每一路直播画面原封不动地分别发到你的设备上，由你的电视端自己完成画面的拼接和显示。

　　在客户端多视图模式中，多个数据源被传送给播放器

　　在网络传输层面，负责分发视频的服务器（CDN）只管把 A、B、C、D 四路直播分别送到你的设备。同时，App 会告诉播放器一份”布局说明书”：该显示哪几路画面、每块画面多大、放在屏幕哪个位置、哪一块的声音是开着的。

　　播放器拿到这份说明书后，同时连上多路直播信号，各自管理画质切换和缓存，还要保证所有画面的进度同步（比如不能在 A 画面的进球已经播了，B 画面还在慢半拍）。最终，播放器把所有画面像贴窗花一样贴到 App 的屏幕上。

　　这种架构的最大优势在于灵活性。由于云端不做合成，运营方不再受限于一组预先渲染好的固定布局，理论上可以支持任意输入组合和任意排布方式，而无需为每种组合再拉起新的云编码实例。

　　但代价也很直接：所有”重活”都丢给了你的设备。而且同样是客户端方案，“怎么干这些重活”也分两派：

　　1、笨办法：开多个播放器。早期的做法就很简单粗暴。要显示四路画面？那就在你的电视上同时打开四个独立的播放器，各干各的。就像在一台电脑上同时开四个视频窗口一样，每个窗口都占用一份 CPU 和内存。性能好的设备还扛得住，差一点的直接卡死。

　　多个独立播放器同时运行，除了吃性能，还有一个容易被忽视的深坑——网络带宽的内耗。每个播放器都活在自己的‘信息茧房’里，它们不知道旁边还有兄弟在抢网速。当四个播放器各自为政、拼命抢占带宽去填满自己的缓存时，由于 TCP 协议的公平性机制，总有一个播放器跑得飞快、另一个慢如蜗牛。更糟糕的是，ABR 算法会因此产生严重误判：某个时刻只有播放器 A 在下载，它误以为网速很快，于是把画质切高；下一瞬间四个播放器同时并发下载，它又误以为网络拥堵，慌忙把画质切低。这种‘忽快忽慢’的误判会让画面画质频繁波动、加载异常缓慢。

　　Tiledmedia 曾做过一个直观的对比测试：在 iPad 上同时运行 4 个独立的 AVPlayer，播放同一个‘计时时钟’的直播流。即便网络带宽非常充裕，短短几秒钟后，四个画面上的时间码就出现了肉眼可见的明显偏差，完全无法做到帧级同步。这意味着，观众在同一个屏幕上看四场同时进行的比赛时，可能 A 画面已经进球庆祝了，B 画面还在慢半拍地传球——这种体验对体育直播来说是灾难性的。

　　2、聪明办法：一个播放器搞定一切。 Tiledmedia 走了另一条路——只用一个播放器，在同一块”画布”上同时处理多路画面。就像在一台电脑上用一个浏览器打开四个标签页，而不是同时开四个浏览器各开一个页面。一个浏览器统一管理，资源占用比四个浏览器小得多。

　　如果实现方式是启动多个完全独立的解码流水线，在普通智能电视和低端流媒体棒（dongle）上，很快就会在 CPU、GPU 和内存上撞到天花板。只有当在一个专用播放器内高效解决多路解码、ABR 与多路同步问题时，客户端多画面才真正可行。

　　Tiledmedia 提供的就是这种客户端方案：单一播放器承担拉流、拼接、同步和展示的全链路工作。

　　这套方案的核心，是对编解码的 “分块（tiling）”能力 的运用。简单来说，就是每路直播流在编码时就按标准规格切成若干块，播放器收到后，像拼乐高一样在本地完成多路流的拼接与合成，而不是在云端完成。

　　这套技术并非凭空而来——它脱胎于 Tiledmedia 在更苛刻的 VR 全景视频领域的技术积累。在 VR 场景中，同一时刻需要流畅切换和同步多达 25 路以上 的分块流，对同步精度和切换速度的要求远超普通电视多画面。正因为网络接口、分段拉取引擎和 ABR 逻辑从底层就是为“多流”而原生设计的，它天然具备几项独特优势：

　　1、极致的带宽效率。 统一的 ABR 引擎能根据每个窗口在屏幕上的实际显示尺寸，智能地为每路流选取最合适的码率档位——比如四宫格中每个小窗只需 1080p 码流，而不是傻乎乎地全拉 4K，避免带宽浪费。

　　2、一套编码适配所有设备。 后端只需准备一组常规的码率阶梯，就能同时服务于所有前端设备，无需为不同终端维护多套复杂的转码配置。

　　3、理论上无限的窗口数量。 由于所有解码和渲染都由同一个播放器引擎集中调度，只要能通过 UI 展示得下，就可以突破终端系统对“并行播放器数量”的硬件限制，哪怕只支持单路硬解的设备也能流畅播放多画面。

　　此外，客户端多画面还有一个容易被忽视但对体验很关键的优势：音频焦点。因为所有画面都在本地播放，当你想把声音从 A 球场切到 B 球场时，播放器只需把 A 的声音关掉、B 的声音打开——就像戴着耳机切歌一样，几乎瞬间完成，没有任何卡顿或延迟。

　　而在服务端和打包端方案中，切换声音往往要重新加载一些数据（业内叫”manifest 切换”，可以理解为播放器要重新查一遍”菜单”才知道新的声音在哪），这个过程虽然很短，但用户能感觉到一次短暂的卡顿或延迟。

　　除了 Tiledmedia 的单播放器方案外，目前也有多款商业播放器 SDK 把多画面作为内建特性。Dolby OptiView 在其 SDK 中提供 MultiViewPlayer，任何已经使用 OptiView 播放器的服务，都可以直接在其基础上加一层多画面能力。Bitmovin 的 Player SDK 同样在 iOS、tvOS 和 visionOS 上支持多画面，通过一个框架在同一屏幕上管理最多 5 个播放器实例。需要强调的是，这些更接近“播放器产品的一个功能点”，而 Tiledmedia、Skreens、Broadpeak、Synamedia 这些方案则是从底层架构出发、专门为多画面场景设计的系统级方案。

　　架构三：打包端多画面（Packager-Side Multiview）

　　在打包端多画面架构中，多画面并不是在云合成器或重型客户端里完成，而是在打包/源站层实现的。所有机位或节目源首先都被编码成常规的 ABR 码率梯度。

　　采用打包器端的方法时，可以通过使用 HEVC 或 VVC 技术，在打包器中实现多视图的显示

　　这种方案的核心角色，是打包器旁边的一个”布局调度员”（技术上叫 Multiview Layout Service，多画面布局服务）。它的工作流程是这样的：

　　你在 App 上选择了想看的四场比赛和布局方式；

　　“布局调度员”收到你的选择，把它翻译成一组指令：哪个格子放哪路画面、每个格子多大、放在哪个位置；

　　打包器按照这些指令，把已经编码好的各路视频片段像拼积木一样组装起来，输出一条看起来像普通直播的视频流。

　　最终送到你设备上的，就是一条”拼装好的”视频流——你的播放器像播放普通直播一样播放它即可。

　　不过，这种方案有一个重要前提：所有输入的直播画面必须用同一种”语言”来压缩（目前主要是 HEVC 或更新的 VVC 编码格式），而且压缩时就要预留好可以拼接的”接口”。你可以把它想象成乐高积木，每块积木的接口规格必须一致，才能自由拼合。

　　好消息是，只要这个前提满足，打包器就不需要像服务端那样对整个画面重新压缩，它只做一些轻量的”头部信息改写”（相当于换个标签贴纸），效率非常高。而你的电视只要支持 HEVC 解码（目前市面上大部分 4K 电视都支持），就能直接播放。

　　从运营方视角看，这种架构把多画面从一个“额外转码工程”，变成了一个“增量打包能力”的问题：每路输入频道仍然只需要编码一次（就像传统线性频道一样），而多画面布局服务和源站则在打包层面，通过更新 manifest 和 tile 映射表，把这些编码好的片段重混成各种多画面变体。

　　属于这一类方案的公司主要有 Broadpeak 和 Synamedia。Broadpeak 把自己的实现称为 Multiview，采用“multi-package（多重打包）”架构，是其源站打包和云 DVR 技术的延伸能力。Multiview 与 Broadpeak 的源站打包与个性化栈处于同一层级，既可以作为授权软件部署在客户自有环境中，也可以以 SaaS 形式运行在 Broadpeak 云平台，或者以全托管服务方式交付。

　　Synamedia 则将方案包装为 Synamedia Multiview，构建在其 Quortex 云视频平台之上。截至 2026 年 6 月，承载这套技术的 Synamedia 视频网络业务（含 Quortex）正在被 Lumine Group 收购，交易“预计在不久的将来完成”。这意味着，多画面技术栈未来会以 Quortex 品牌存在于 Lumine 体系之下，而不是长期以 Synamedia 自有产品线的形式延续。

　　决策矩阵：如何做多画面架构选型

　　选择多视图架构时需要考虑的因素

　　在了解了三种架构和主要厂商之后，我们可以从几个关键维度入手，对比评估它们的适用场景。以上表格给出了详细对比，从处理位置（即多画面在何处被构建）开始，这一点会直接影响设备兼容性。

　　兼容性：服务端＞打包端＞客户端

　　如前所述，服务端多画面的最大卖点就是兼容性：任何能播放单路直播流的设备，都可以无感知地播放多画面频道。与之相对地，客户端多画面则对设备要求更高——很多普通智能电视和低端流媒体棒（比如几百块的 HDMI 小棒子）同时最多只能流畅播放 1-2 路视频，四宫格基本带不动。这意味着真正稳定的多画面体验，目前主要集中在 Apple TV、高端安卓电视盒子这类性能较强的设备上。

　　打包端多画面在终端适配上更接近服务端，只要设备具备 HEVC 多画面流的解码能力，就可以直接播放这种 tiled 输出，而不需要在播放器上做太多额外改动。

　　从“静态多画面”到 BYOMV

　　第一代多画面服务本质上都是“一刀切”：所有用户看到的是同一套布局，用户能做的定制很有限，顶多就是切频道。这一模型很好地验证了多画面的价值，但几乎没有给“个性化”和“第一方数据”留下操作空间。大多数早期多画面的项目，实质上就是开通了一条或几条“固定多画面频道”，不支持用户自定义。

　　想象一下：你是个足球迷，同时关注四场小组赛，但你想看的四场和你朋友想看的完全不一样。“固定拼盘”满足不了你们俩，你需要的是一块空白画布，自己往里面填想看的比赛。

　　过去几年，行业的重心逐渐转向更强的个性化能力，BYOMV（Build Your Own Multiview，即自建多画面）也由此成为一个明确的术语。现在，YouTube TV、Sunday Ticket、ESPN、Peacock 等服务，已经允许用户自由选择每一个窗口里要播放哪场比赛、哪个机位。用户的心智也从“这是给你的一个四宫格频道”，转变为“这是一个画布，你自己填满它”。

　　从理论上看，三种架构都可以支持这种 per-user 级别的灵活性。真正的问题在于：你要为这种“自定义自由度”在大规模场景下付出多大的成本。

　　个性化的成本结构

　　在服务端架构下，每一个独一无二的多画面频道，都需要对应一条实时合成编码流水线。如果你要对几十万观众全面开放 BYOMV，云端转码账单会非常难看。现实中，大部分服务会对多画面频道的数量设一个上限，并在用户之间做一定程度的共享：比如，把某地区的两场 NFL 比赛组合成一条固定的多画面频道，然后把所有看这两场本地比赛的用户都指到这一条频道上。

　　在客户端多画面架构下，你几乎没有额外编码成本：服务只需要把各路直播流按常规方式提供出来，播放器根据用户选定的组合拉取相应流，并在本地完成拼接渲染。

　　在打包端多画面中，每条输入频道同样只需要编码一次，打包器通过在 manifest 层重新组合 tile 来生成多种多画面组合，完全避免了“按布局重复转码”的成本。增量成本主要体现在打包端的复杂度提升，这部分通常远低于服务端多路转码，但会略高于“纯客户端”的做法。

　　带宽成本

　　从带宽消耗来看，服务端多画面和单路频道几乎是等价的：无论观众此刻是在看一场比赛，还是在四宫格里同时看 4 场，只要输出是同一条 4K 或 HD 频道，所需码率基本一致。

　　客户端方案的带宽消耗则差异巨大，取决于具体怎么实现。用前面说的”笨办法”（四个独立播放器），每个播放器”不知道”自己只是四分之一个屏幕，可能傻乎乎地去拉 4K 最高画质的视频再缩小显示。四个播放器一起拉？你的带宽消耗可能直接翻四倍——相当于同时看四场独立的 4K 直播，你家的网速和流量扛不扛得住就是另一个问题了。

　　Tiledmedia 的单播放器方案则采取了完全不同的策略：它只会为每个 tile 选取与其实际显示像素相匹配的梯度档位。比如，在一块 4K 屏幕上的 4 宫格布局中，每个 quarter-screen tile 实际上只需要大约 1080p 的码流即可。4 路 1080p 的整体压缩效率理论上略逊于单路 4K 编码，但差距并不大。对于打包端多画面来说，道理类似，只是这套逻辑发生在源站和打包器，而不是播放器端。其整体带宽效率略逊于服务端，但远远好过“4 倍 4K”的糟糕情况。

　　广告集成

　　接下来聊一个运营方非常关心的话题：怎么在多画面里插广告、怎么赚钱。

　　服务端方案在这方面最省心。因为最终输出的就是一条”普通”的视频流，现有的广告系统（业内叫 DAI，动态广告插入，就是你看直播时自动给你塞的那些个性化广告）可以直接接上，完全不用改造。

　　Skreens 在推广 Tessera 时就着重强调这一点：对广告技术栈来说，它就是一个“零改造”的接入方式。在 BYOMV 场景下，理论上可以做到按观众级别的个性化广告，但那要求为每个用户单独输一条编码输出。否则，只要一群用户共享同一条多画面频道，他们看到的 stitched ad（拼接广告）就完全一致。

　　客户端多画面的实现，则以不同方式打开了真正“按观众级别个性化广告”的可能性。Tiledmedia 的模型不是像传统 DAI 那样做整段全屏插播，而是直接把广告作为一个 tile 镶嵌在多画面布局里。「Tiledmedia 的广告专题页面」把这类方案称为“personalized multiview advertising（个性化多画面广告）”，并这样描述：“发行方和广告主可以选择把广告放在屏幕角落的小窗口（画中画），或者与主内容并排展示，或任何其他自定义布局。整个方案可以完全定制，并支持个性化……Wilma 可能会在她的画中画里看到一条软饮广告，而 Fred 则会在同一位置看到一则运动鞋广告。”

　　Tiledmedia 提供的个性化多视角广告服务

　　这种方式让用户始终停留在多画面体验中，而不是被“抽离”到一段全屏广告中，同时也具备家庭级、账号级的定向能力。相应的技术门槛也更高：广告决策在播放器侧完成，意味着广告请求、曝光监测、频控等逻辑都要在客户端打通，而不再仅仅依赖服务端的 DAI 工作流。

　　打包端多画面在实践中离传统 DAI 模型最近，但又在其基础上做了拓展。由于每一种多画面组合在打包层都可以视为一条独立清单，它完全可以在 DAI 系统中注册为独立的广告位。Broadpeak 的 Damien Sterkers 在最近一次 Streaming Learning Center 的访谈中解释道：“我们只是向广告服务器声明：我们现在有更多的可售库存，它就可以针对这个多画面应用单独做广告投放决策。”

　　他还提到，当视频合成器能够控制布局时，会出现一些新的广告形式：“传统的 L 型 Banner，通常是把视频画面缩小，然后在旁边空白区域贴一张静态广告图。而在多画面场景里，这块空间可以由一段实时视频来承载。”

　　Synamedia 的产品页面并未直接谈广告，但其基于 API 的“业务逻辑层”用来做频道选择，天然就是在打包层接入广告决策的锚点。

　　同步与时延

　　最后是同步和延迟，这是三种架构在日常运营中体验差异最直观的地方。

　　服务端和打包端方案会在”出厂”前就把所有画面的时间线对齐，然后作为一条流发出去——你的播放器只需要跟着一个时间线走，不存在”这个画面快了那个画面慢了”的问题。

　　客户端方案则要同时追踪多条时间线、管理多份缓存，要做到所有画面严格同步会更难一些。但它在另一个方面更有优势：当你切换声音或调整布局时，因为所有操作都在本地完成，响应速度往往更快、过渡更丝滑。

　　集成工作量：不同架构的落地路径

　　从落地实施的视角看，服务端多画面主要是一项后端项目。像 Skreens 这类多路重编码方案，需要你在云上或本地机房部署合成 + 编码集群，把它与现有编码器、源站、控制平面串联起来，并把最终多画面频道在内容目录中暴露给前端。客户端这边，可以继续沿用现有播放器，只需要在产品与前端层面，把多画面频道以合适的形式加入 UI 即可。

　　客户端多画面则充分复用现有的直播码率梯度，每路比赛或机位依旧按照原有方式编码。工作重心转移到了播放器 SDK 和 App：你需要一套信令或元数据机制，让 App 知道要打开哪些流、如何保持它们的同步、以及如何确保目标设备有足够的算力支撑多路解码和拼接。编码器和源站栈的改动非常有限。

　　打包端多画面（如 Broadpeak 和 Synamedia 的方案）部署在源站 / 打包层，输入频道依旧只编码一次，由多画面服务在打包时完成组合。集成路径是：在源站启用支持 tiling 的打包逻辑，部署多画面布局服务，并确保现有播放器具备 HEVC 解码能力并能解析布局元数据。整体来说，相比“完全客户端化”的方案，客户端改动更小。

　　结论：Multiview 不是一个“小功能”，而是一项架构决策

　　下一次你在电视上按下”多画面”按钮时，背后发生的事情，远比屏幕分成四格要复杂得多。这不只是一个功能开关，而是一项牵动设备兼容性、运营成本和用户体验的架构选择。

　　它会决定你能覆盖多大范围的设备基数，你在大规模运营时要付出多少基础设施成本，以及你的产品团队在观众体验上的掌控力度有多大。服务端、打包端和客户端这三条路线，在这些维度上的取舍都是真实而截然不同的。正确的选择取决于你的设备、个性化诉求、既有基础设施，以及你整体的成本模型。本文的目的，就是为这项决策提供一个足够清晰的分析框架。

　　值得注意的是，这三条路线并非互斥。在实际部署中，不少运营方已经在探索混合架构——比如用服务端方案快速覆盖低端设备和固定布局场景，同时在高端设备上启用客户端方案来释放个性化能力。选择一种架构并不意味着必须押注一条路走到黑，而是在当前阶段的设备分布、用户预期和预算之间找到最务实的起步点。

　　从更长远的视角看，多画面的演进方向已经很清晰：从”平台给你看什么”走向”你自己决定看什么”。这个趋势的终局不只是 BYOMV，而是整个观赛体验的”去导播化”——观众不再被动接受导播的镜头语言，而是主动选择自己的视角组合。当这件事真正大规模发生时，多画面就不再只是一个产品功能，而会成为体育直播交互范式的一次根本转变。

　　而这，恰恰是本届世界杯正在悄悄展示给我们的信号。当你在屏幕上同时看到四个不同视角的画面时，你享受的除了比赛之外，也是流媒体技术正在重新定义”看球”这件事本身。

　　本文来源：【探显家Attention】公众号

　　版权归原作者所有，仅用于分享交流。

责任编辑：赵莹