为什么一套视频系统能服务30年，却在流媒体时代被迫拆分重组？1992年诞生的复用器技术至今仍在DVB广播中稳定运行，但OTT平台却要把同一功能拆成三四个系统来做。这背后不是技术倒退，而是整个分发逻辑的底层重构。
一、1992年的"斧头"：为什么老技术死不了
复用器（Multiplexer）诞生于1992年的DVB广播时代。188字节的传输流结构、各种表格定义、传输间隔设计——这套架构如此精巧，以至于经历了数代计算机更迭依然运转如初。
原文把它比作斧头：简单、可靠、完成本职工作。没有冗余，没有过度设计，每个字节都有明确用途。这种极简主义让它成为广播电视的常青树。
但互联网来了。IP传输彻底改变了游戏规则。
二、OTT早期的"偷懒"方案：把老技术切片上架
最早的OTT平台没有重新发明轮子。它们直接把DVB的传输流切成小片段，通过HTTP发送。这个过渡方案解决了三个实际问题：
自适应码率——带宽收窄时播放器自动降级。极端情况下128Kbps只能看到冻结画面，但音频评论照常播放。
多设备兼容——高端设备要4K，老旧终端只能播标清，同一套源文件要服务全谱系硬件。
渐进式加载——HTTP分段比持续流更适合互联网的不稳定特性。
但这毕竟是权宜之计。传输流里塞满了DVB广播专用的服务表格，在互联网场景纯属浪费。
三、MP4迁移：10%码率节省背后的设备战争
行业最终转向MP4容器。核心收益明确：砍掉DVB专属的服务表格，码率节省约10%。
苹果的HLS协议经历了典型演进——起步用传输流，后期全面切到MP4。架构很清晰：主清单（Master Manifest）描述可用画质档位，媒体清单指向具体视频片段。
MPEG DASH则原生为MP4设计，功能集更丰富。
理论上MP4能解锁更长GOP（Group of Pictures，画面组）——DVB时代0.5秒，OTT可以做到10秒。还有金字塔型B帧结构，压缩效率更高。
但现实很骨感。部分设备不支持长GOP，某些播放器遇到B帧金字塔直接崩溃，缓冲区和解码器规格限制千差万别。工程师永远在"最优编码理论"和"终端设备实测"之间走钢丝。
四、DRM碎片化：一个内容商要养三套加密体系
如果你是正经运营商，必须同时支持三大DRM（数字版权管理）系统：
Widevine（谷歌）——安卓设备和浏览器
FairPlay（苹果）——iPhone、iPad、Apple TV
PlayReady（微软）——三星、LG等智能电视
三套系统，三种加密格式。最少需要4个播放列表，实际运营中往往要做7个——因为有些设备明明规格支持，实际播放就是挑格式。
这还没完。图文电视（Teletext）在DVB是一种技术，OTT里要支持5种格式。DASH标准内就包含两种：TTML和WebVTT。
复杂度不是线性叠加，是指数爆炸。
五、整合还是拆分？架构选择的三个锚点
回到开篇的问题：转码器、打包器、DRM/CAS扰码器，能不能合一？
原文给出的判断框架很务实——取决于三个变量：
网络架构。边缘节点多、带宽贵的环境，倾向于前端集中处理，减少重复传输。云原生架构则更灵活。
内容保护要求。高价值内容需要硬件级安全，可能强制分离加密模块。普通内容可以软件方案一体化。
终端设备多样性。设备谱系越杂，中间层越厚，打包环节越难合并。如果只做苹果生态，复杂度直接砍半。
没有标准答案，只有场景适配。
六、为什么这值得技术人关注
视频传输链的演进是个经典案例：底层技术（编解码、容器格式）进步缓慢且保守，中间层（打包、DRM）因商业割据而碎片化，应用层（播放器、用户体验）被迫消化所有复杂性。
30年历史的复用器还活着，说明基础设施的寿命远超预期。但OTT时代的设备爆炸和内容保护战争，正在逼迫行业重新划分系统边界。
整合派追求运维简化，拆分派追求灵活适配。真正的工程智慧，是看清自己处于哪个约束集合里——然后承认，有些"低效"是为了活下去必须支付的税。
毕竟，能播放的烂画质，胜过无法解码的完美压缩。
热门跟贴