采用分离式多码率文件会比单文件内嵌多码率多出相当一部分音频冗余，但真正吃掉存储空间的不是封装本身，而是转码产生的各清晰度完整副本。
为什么点播系统绕不开多码率
用户手里的设备五花八门，办公室的千兆光纤和地铁里的4G信号完全不是一个体验，如果平台只给一个码率，要么高清用户嫌卡，要么低清用户嫌糊，所以点播平台普遍的做法是把同一部片子转成多档码率，让播放器根据带宽自动选，这个动作在行业里叫多码率自适应。
但很多人把"转码"和"封装"搞混了，转码是把视频重新编码，生成不同清晰度的独立文件；封装是给这些文件套容器格式，比如MP4、TS，多码率封装讨论的是：这些不同码率的视频流，你用什么方式装、怎么组织,存储开销差别很大。
多码率封装存储差异到底有多大
每档码率一套完整文件
这是最笨也最常见的做法，平台生成720P、1080P、4K三档，每档都是独立的MP4文件，各自包含视频轨和音频轨，存储占用就是三份完整视频的总和，比如一部90分钟的电影，1080P大概2GB，4K可能8GB,三档加起来轻松超过12GB。
单文件多码率复用音频
MP4容器支持在一个文件里塞多条视频轨，音频轨可以共用一份，苹果的HLS和部分流媒体平台会用类似思路，因为音频码率通常只有视频的十分之一左右,这种做法能省下一部分重复的音频存储。
但注意，省下的比例很有限，一部电影的音轨按192Kbps算，90分钟也就130MB左右，三档码率如果每档都带独立音轨，总共多出约260MB，相比视频本身动辄几个GB的体积,这个节省在总存储里只是零头。
流式封装分片存储
现在点播平台主流做法是HLS或DASH，视频被切成一个个几秒的小分片，每个分片单独存储，多码率意味着同一个时间点有多个不同清晰度的分片文件，这种
分片封装的存储占用和方案一没有本质区别,仍然是多档码率的完整副本总和。
但分片模式有个额外的存储开销：分片会产生元数据文件（m3u8索引），以及时间对齐造成的末尾填充数据，每个分片为了保持关键帧对齐，编码时可能产生少量冗余字节，大量分片累计起来也是个不小的数字，据统计，分片封装的额外开销通常占整体存储的1%到3%，档位越多,浪费越明显。
| 封装方式 | 视频存储 | 音频存储 | 额外开销 |
|---|---|---|---|
| 多文件独立封装 | 各档完整副本 | 各档各一份 | 几乎为零 |
| 单文件多码率 | 各轨完整副本 | 共享一份 | 容器索引很小 |
| 分片流式封装 | 各档完整副本 | 各档各一份 | 分片元数据+填充数据 |
核心结论是：多码率封装对存储的影响，大头在转码生成的完整副本，封装格式的选择只影响冗余比例，不改变量级。
多码率封装与单码率存储开销对比
单码率存储逻辑很简单：一个视频一个文件，存储量等于视频大小，多码率则是几何级数增长，但不是线性翻倍那么理想。
这里有个关键细节：压制多码率时，不同清晰度的编码效率不同，1080P的2Mbps码率和4K的15Mbps码率，后者的体积是前者的7倍多，而不是简单的分辨率倍数关系，所以一个4K原片转出的四档码率，总存储可能达到原片的6到10倍。
视频网站采购存储时通常按TB算成本，一个中型点播平台假设有10万小时内容，单码率存储大约需要300TB到500TB，做成四档多码率，直接跳到2PB到3PB，按企业级存储每TB每月几十元的成本算,这个差距是六位数级别的月支出。
所以在业务早期，很多平台会采取折中策略：只做两档码率（标清+高清），或者对热门内容做多码率，冷门内容只保留单码率,这本质上是拿存储换体验。
点播平台如何降低多码率存储成本
冷热分层是第一个突破口
热播剧上线第一周被密集访问，三个月后可能一周都没人点一次，行业共识认为，90%的播放流量集中在10%的内容上挪到低频存储池，新内容放高性能存储，成本能降一大截，云厂商的对象存储一般都有标准、低频、归档三档,价格差距可达数倍。
编码参数比封装格式更能省钱
与其纠结用MP4还是HLS，不如把码率控制做好，同等画质下，使用更新的编码标准H.265/H.266比H.264能省30%到50%的码率，多码率封装前先在编码环节省一顿,存储压力自然小了。
分片合并和垃圾清理
分片封装最大的隐藏浪费是孤儿分片转码失败或者中途取消产生的残留文件，实操中建议定时跑脚本扫描存储桶，把没有索引文件引用的孤立分片清理掉，一个大平台每天因转码中断产生的孤儿分片可能有几十GB，某些播放器会请求不同码率的相同分片，导致缓存服务器重复命中,这属于CDN层面的冗余。
具体操作路径：登录对象存储控制台，开启生命周期规则，将超过180天未访问的分片自动转低频，超过365天转归档，多码率的老版本转码副本，也可以只保留最高码率母版,其余档位按需重新转码。
地域节点对存储占用的真实影响
多码率封装的存储账本不能只算中心源站，还要算CDN边缘节点，点播平台的流量分两个维度：源站存全量内容命中的是长尾点播，边缘节点缓存热门内容承担的是高并发访问，按地域部署时，华北、华东、华南的节点缓存策略不同,会导致同一份多码率内容在各地重复存储。
举个例子：一部热门剧有六档码率，共42GB，中心源站存一份，三个区域节点的缓存规则是"热门内容全码率缓存"，那就意味着这部电视剧在边缘节点就要占126GB，如果运营策略改成"边缘只缓存中低码率档位，高码率回源拉取"，存储直接砍掉一半以上，做地域化运营时,这是个很实际的价格优化点。
按存储容量还是按请求次数计费，不同云厂商的计价模型差别挺大,带宽型点播平台选按流量计费更划算。
Q&A：关于多码率封装存储的几个高频问题
问：多码率封装是不是文件越多就越浪费存储？
答：不完全是，文件数量多会带来元数据开销和碎片化问题，但真正的大头是各档码率视频流的体积总和，只要转码生成了多档码率，无论怎么封装，视频数据本身就占了绝大部分体积，音频复用、索引优化这些手段能省的非常有限，省下的量一般不超过总存储的2%。
问：点播平台存储选型买HLS还是MP4划算？
答：看兼容性需求，MP4适合点播下载和兼容老设备，HLS适合流式播放和防盗链，存储成本上两者差距不大，但HLS分片会多出索引文件和分片对齐开销，比值约在2%到5%，如果你面向的是iOS和Web端的OTT业务，HLS是事实标准；如果做短视频App内的横屏播放器,MP4内嵌多码率的方案反而简单直接。
问：多码率存储能不能用NAS本地存储替代云存储？
答：中小型点播平台通常不建议，自己做本地存储意味着要自建机柜、购置硬盘、维护多副本和容灾系统，而且CDN回源要走公网带宽，云存储的优势不在单价，而在生命周期管理和跨地域分发，多码率封装带来的数据量增长，在本地存储方案下会被放大，因为扩容周期长，前期就要预留富余容量,而这些富余容量在业务平稳期完全是沉没成本。