未压缩视频数据量计算全解析：从公式推导到工程实践

视频数据量算不准，后面所有事都是白搭。做存储方案的时候容量拍脑袋定，结果录到一半磁盘爆了；做带宽预算的时候少算一个零，推流端卡成幻灯片；做剪辑工作站选型的时候没搞清码率结构，买回来的盘阵列跑不满实时回放。这类问题我在实际项目里见过太多次，根子往往不在设备上，而在最开始那一步——未压缩视频数据到底有多大，很多人只是"大概估一下"，没有真正把计算方式吃透。这篇内容就是把这个看似基础、实则处处是坑的问题拆开讲清楚：未压缩视频的数据量由哪些参数决定、公式怎么推导、不同色度采样和位深下差多少、实际工程里怎么快速估算和验证。适合刚入行的音视频开发、做监控存储规划的工程人员、剪辑与调色工作站的搭建者，以及任何需要跟"原始视频体积"打交道的人。哪怕你之前只会用在线计算器点两下，看完也能自己把账算明白。

1. 先把账算明白：未压缩视频数据量的底层逻辑

1.1 为什么"未压缩"这三个字决定了计算方式

要理解未压缩视频的数据量，先得理解压缩视频为什么难算。压缩后的视频，体积取决于编码器、码率控制策略、画面复杂度、运动剧烈程度，同样分辨率同样时长的两段素材，体积可能差好几倍，你没法用一个干净公式算出来，只能靠码率乘以时长去估。而未压缩视频不一样，它没有经过任何熵编码、没有帧间预测、没有量化，每一个像素的每一个分量都老老实实按固定位宽存着，所以它的数据量是可以被精确推导出来的——这就是计算方式的立足点。

换句话说，未压缩视频的数据量是一个"确定性"问题，输入参数定了，输出就唯一。这个确定性带来两个好处：一是可以事前精确规划存储和带宽，不用留巨大的安全余量；二是可以反过来验证——你拿到一个号称"未压缩"的文件，用公式一算就知道它到底是不是真的没压缩，或者中间被悄悄降了位深、降了采样。我在排查一个采集卡输出异常的问题时，就是靠这个反推发现驱动偷偷把10bit截成了8bit，画面肉眼几乎看不出，但数据量对不上，一算就露馅。

这里要强调一个常见误解：很多人以为"未压缩"就等于"文件很大所以一定是原始数据"。不对。未压缩只描述编码状态，不描述参数配置。一个低分辨率、低帧率、4:2:0、8bit的未压缩视频，体积可能比一个高规格压缩视频还小。所以计算方式必须建立在参数之上，而不是建立在"未压缩"这个标签之上。

1.2 一个像素到底占多少：从分量到字节的推导链

未压缩视频数据量的计算，本质是回答一个问题：一帧画面里，所有像素的所有分量，一共占多少比特。推导链条是这样的：先看单个像素由几个分量构成（亮度Y、色度Cb、色度Cr，或者RGB三通道），再看每个分量用多少位（位深），然后看色度采样方式决定了色度分量是不是每个像素都有，最后乘以像素总数和帧数。

用最干净的模型起步：假设RGB 4:4:4、每通道8bit，那么一个像素就是3个分量乘以8bit等于24bit，也就是3字节。一帧1920×1080的画面有2073600个像素，乘以3字节就是6220800字节，约5.93MB。一秒30帧就是约178MB，一小时就是约640GB。这个数字先记住，后面所有变体都是在这个基础上做加减乘除。

但真实工程里更常见的是YUV色彩模型，因为人眼对亮度敏感、对色度不敏感，所以色度可以降采样，这就是4:2:2和4:2:0的由来。这里必须把采样方式讲透，因为它是数据量差异的最大来源之一。4:4:4表示每个像素都有独立的Y、Cb、Cr；4:2:2表示水平方向每两个像素共享一组色度，色度分量数量减半；4:2:0表示水平和垂直方向都每两个像素共享一组色度，色度分量数量减到四分之一。注意4:2:0的"0"不是"没有色度"，而是垂直方向也做了减半，这个命名容易误导新手，实际色度是存在的，只是密度低。

把分量数量算清楚，公式就出来了。设宽W、高H、帧率F、位深B（每个分量位数）、色度采样因子为S（4:4:4时S=3，4:2:2时S=2，4:2:0时S=1.5），那么每秒数据量（字节）约等于 W × H × F × B × S ÷ 8。这个S的取值是很多人算错的地方，4:2:0为什么是1.5而不是1？因为亮度分量每个像素一个，占1份；两个色度分量合计每四个像素一组，平均每个像素0.5份，加起来1.5份。这个1.5是"平均每像素分量数"，不是整数，所以算出来会有小数，别慌，那是正常的。

1.3 位深、帧率、分辨率：三个乘数各自的杀伤力

理解了公式结构，就能看清每个参数对数据量的影响权重。分辨率是平方级影响，宽高各翻倍，像素数翻四倍，数据量也翻四倍；帧率是线性影响，翻倍就是翻倍；位深也是线性影响，8bit到10bit是1.25倍，到12bit是1.5倍。这三个乘数叠在一起，差异会非常惊人。

举个实际对比：1080p30、4:2:0、8bit，每秒约 W×H×F×B×S÷8 = 1920×1080×30×8×1.5÷8，算下来约93.3MB/s。同样参数换成4K60、4:2:2、10bit，就是3840×2160×60×10×2÷8，约1244MB/s，差了十三倍多。这个对比说明什么？说明在规划阶段，参数选型比"要不要压缩"更能决定数据规模。很多项目一上来就纠结编码格式，其实先把采集和存储的原始数据规格定清楚，才是真正影响成本的那一步。

位深这个参数特别值得单独说，因为它最容易被忽视。8bit每个分量256级，10bit是1024级，12bit是4096级。位深提升带来的不只是数据量增加，还有调色空间和宽容度的提升，所以专业调色和HDR流程普遍用10bit甚至12bit。但代价是实打实的数据量增长，而且这个增长是乘在公式里的，不是加一点。我见过有团队按8bit规划了存储，后期流程升级到10bit，容量直接不够用，返工成本很高。所以规划时如果未来可能上位深，最好按目标位深算，别按当前位深算。

2. 公式落地：不同参数组合下的精确计算与对照

2.1 标准公式的完整形态与单位换算

把前面的推导收拢成一个可以直接用的公式。未压缩视频每秒数据量（字节）：

每秒字节数 = 宽 × 高 × 帧率 × 位深 × 平均每像素分量数 ÷ 8

其中平均每像素分量数：4:4:4取3，4:2:2取2，4:2:0取1.5。总数据量再乘以时长（秒）。如果要换成更常用的单位，1GB按1000×1000×1000字节算（厂商标称常用），或者按1024×1024×1024算（操作系统显示常用），这两个口径差约7%，规划存储时要说清楚用哪个，否则会出现"算出来够用、实际差一截"的情况。

这里有个实操细节：帧率如果不是整数，比如29.97、59.94，别直接按30和60算，误差会累积。29.97帧每秒，一小时下来和30帧差约108帧，按1080p算就是几百MB的偏差。正确做法是用实际帧率的小数值代入，或者用"帧率分子/分母"的精确形式。这个细节在短片段里无所谓，在长时录制和存储规划里就是实打实的容量差。

还有一个容易混淆的点：位深是"每个分量"的位数，不是"每个像素"的位数。有人把10bit理解成每像素10bit，那算出来只有实际的三分之一到二分之一，错得离谱。记住位深是分量级的，乘平均分量数之后才是每像素的比特数。

2.2 常见规格对照表：从1080p到8K的实测数据

光讲公式不够直观，直接上对照表。下表按每秒数据量和每小时数据量两个维度列出常见组合，单位用GB，按1GB=1000^3字节计。

看这张表要有几个直觉：1080p30的4:2:0 8bit是"基准档"，约93MB/s；往上每升一档，量级都在跳。4K60 4:2:2 10bit已经到1.2GB/s，这个速度对存储的持续写入能力是硬考验，普通机械盘阵列都未必扛得住长时间稳定写入。8K那行更是提醒我们，未压缩8K基本不是普通工作流能碰的，必须靠高速存储或者干脆走压缩采集。

表格里的数字是理论值，实际文件还会有容器头、对齐填充等少量开销，通常可以忽略，但在精确到字节的场合要留出千分之几的余量。另外注意，这里的"每小时"是按3600秒算的，如果录制有丢帧或者变帧率，实际时长对应的帧数会变，数据量也跟着变。

2.3 反向验算：拿到文件怎么判断参数是否被改过

公式不仅能正着算，还能反着用，这在排查问题时特别有用。方法很简单：拿到一个视频文件，读出它的总字节数、总帧数、分辨率，反推平均每像素占多少比特，再对照它声称的采样和位深，看是否吻合。

举个我实际遇到的场景：某采集设备标称输出1080p30、4:2:2、10bit未压缩，但录出来的文件体积明显偏小。用公式正算应该是1920×1080×30×10×2÷8约155.5MB/s，录10秒应该约1.55GB。实际文件只有约1.24GB，反推平均每像素分量数乘以位深约等于16，也就是8bit的4:2:2或者10bit的4:2:0，总之不是标称的10bit 4:2:2。进一步用工具读像素格式，确认是驱动把10bit降成了8bit。这个排查过程没有公式根本无从下手，因为画面看起来完全正常。

反向验算还有个用途：判断一个文件是不是真的"未压缩"。如果反推出来的每像素比特数远低于理论值，那它一定经过了压缩，只是封装成了某种看起来原始的格式。这个技巧在验收素材、核对供应商交付物时很实用。

3. 工程实操：从参数确认到容量规划的完整流程

3.1 第一步永远是确认像素格式，而不是先套公式

很多人拿到需求就开始套公式，结果参数是错的，算得再准也没用。正确的顺序是：先确认像素格式（Pixel Format），再确认分辨率和帧率，最后确认位深和采样。像素格式这个名字本身就包含了采样和位深信息，比如常见的几种命名里，带"422"的就是4:2:2，带"420"的就是4:2:0，带"10"的一般是10bit，带"P"的可能是平面格式（planar）也可能是打包格式（packed），这两者对数据量的影响其实一样，但对内存布局和传输效率有影响。

为什么强调先确认像素格式？因为不同软件、不同采集卡、不同驱动对同一个"看起来一样"的配置，实际输出的格式可能不同。有的设备标称支持10bit，但默认输出8bit，需要手动在驱动面板里切换；有的软件在预览时用低规格、录制时才用高规格，你按预览估算是错的。我在一个多机位录制项目里就吃过这个亏，预览窗口显示正常，按预览参数估的存储，结果录制端实际用的是更高规格，录到后半程容量告急。从那以后我养成了一个习惯：任何容量规划，都以录制端实际写出的文件头信息为准，不以界面显示为准。

确认像素格式的工具很多，命令行工具读文件头、专业分析软件看像素格式字段、甚至用前面说的反向验算都能交叉验证。关键是养成"先验证再计算"的顺序，别跳过。

3.2 存储规划：把每秒数据量翻译成可用容量和写入压力

算出每秒数据量只是第一步，真正落地要翻译成两个工程指标：可用容量和持续写入速度。容量方面，用每小时数据量乘以录制时长，再留出文件系统开销和余量。余量留多少有讲究：如果是一次性录完再导出，留10%到15%够用；如果是循环覆盖录制（比如监控场景），要考虑覆盖策略和碎片，留20%以上更稳妥；如果是多路并发录制，还要考虑峰值叠加。

写入速度方面，每秒数据量就是持续写入的下限要求，但存储设备的标称速度往往是突发速度或者顺序读速度，持续写入速度可能低不少。机械硬盘单盘持续写入通常在150MB/s到250MB/s之间，具体看盘型和转速；SATA固态通常在400MB/s到550MB/s；NVMe固态能到1GB/s以上甚至更高。对照前面的表，4K60 4:2:2 10bit的1.2GB/s，单块SATA固态都扛不住，必须上NVMe或者做阵列。这里的关键是看"持续"两个字，很多盘跑个几秒很快，跑十分钟就掉速，录制场景恰恰是长时间持续写入，掉速就是丢帧。

还有一个隐藏的坑：多路录制时，如果多路数据写同一块盘，写入压力是叠加的，而且文件系统在并发写入时的效率不如单路顺序写。我一般会按"总数据量乘以1.2到1.3"来估算实际需要的写入带宽，给并发和文件系统开销留余地。这个系数不是拍脑袋，是多次实测下来比较稳的经验值。

3.3 带宽规划：网络传输场景下的额外开销

如果未压缩视频要走网络传输，计算方式还要加一层。原始数据量是净荷，网络传输有协议开销，以太网帧头、IP头、传输层头加起来，实际占用带宽会比净荷高几个百分点。更关键的是，未压缩视频对带宽的稳定性要求极高，因为它没有缓冲余地——压缩视频可以靠缓冲平滑码率波动，未压缩视频的码率是恒定的，一旦网络抖动导致瞬时带宽不足，就是直接丢帧。

实际规划时，我通常按净荷数据量的1.1到1.2倍来估算链路带宽需求，并且优先考虑专用链路或者有服务质量保障的网络。用普通共享网络传未压缩视频，理论带宽够不代表实际能稳定跑，因为共享网络的瞬时占用不可控。这个经验在多个现场传输项目里反复验证过：按净荷算刚好够的链路，实际跑起来总在关键时刻卡一下，留出余量之后就稳了。

另外提醒一点，万兆以太网的理论带宽约1.25GB/s，看起来能覆盖4K60 4:2:2 10bit的1.2GB/s，但实际可用带宽要扣除协议开销，而且单向传输和双向传输的可用带宽不同，多路汇聚时还要考虑交换机背板带宽。所以看到"万兆够用"这种结论，一定要追问是几路、什么方向、什么协议。

4. 踩过的坑与排查实录：那些公式之外的现实问题

4.1 位深被悄悄降级：最隐蔽的数据量偏差

前面提过位深降级的例子，这里展开说排查方法。位深降级的特点是画面肉眼几乎无感，因为8bit和10bit在普通显示器上差异很小，但在数据量上是1.25倍的差距。排查靠三步：第一步用公式正算理论体积，第二步读实际文件体积反推，第三步用分析工具直接读像素格式字段。三步对不上，就是有问题。

我遇到的那次，正算和反推差了约20%，正好对应10bit到8bit的1.25倍关系（反过来8/10=0.8，差20%）。定位到驱动设置里有一个"兼容模式"选项默认开启，开启时输出8bit。关掉之后数据量立刻对上。这个案例说明，公式不只是用来算容量的，它还是一个校验工具，能帮你发现配置层面的隐性偏差。

类似的还有色度采样被降级，4:2:2被降成4:2:0，数据量差三分之一，画面在纯色区域几乎看不出，但在高饱和边缘会有细微差别。反推平均每像素分量数就能发现：算出来是1.5而不是2，就说明被降成了4:2:0。

4.2 帧率不是整数时的累积误差

29.97和59.94这两个帧率在影视流程里很常见，它们不是30和60，差约千分之一。短片段无所谓，长时录制就会累积。按30算一小时是108000帧，按29.97算是107892帧，差108帧。1080p 4:2:0 8bit每帧约3.1MB，108帧就是约335MB的偏差。这个偏差在容量规划里可能刚好卡在临界点上。

更麻烦的是变帧率素材，帧率随时间变化，总帧数不等于帧率乘以时长。这种情况只能按实际总帧数算，不能按平均帧率估。我处理过一批手机录制的素材，标称30帧但实际有掉帧，按30算出来的容量比实际多了近一成，反过来如果按实际帧数算再规划，就准得多。所以规划时如果能拿到实际帧数，优先用帧数；拿不到再用帧率乘时长，并且明确这是估算。

4.3 常见问题速查表

把实际项目里高频出现的问题整理成表，方便对照排查。

这张表里的每一条都来自实际踩坑，不是理论推演。特别是"持续写入"和"并发叠加"这两条，是规划阶段最容易低估、运行阶段最容易出问题的地方。

4.4 几个容易被忽略的实操心得

第一个心得：算容量时把音频也算上。未压缩视频项目里音频占比很小，但如果是多轨未压缩音频，也不能完全忽略。未压缩PCM音频的数据量是采样率×位深×声道数÷8，48kHz、24bit、双声道约288KB/s，一小时约1GB，相对视频是小头，但多轨叠加或者高采样率时值得算一下。

第二个心得：区分"标称容量"和"可用容量"。硬盘标称1TB，实际可用约931GB（按1024进制），再加上文件系统开销，可用更少。规划时按可用容量算，别按标称算，否则差出来的那部分刚好是压垮骆驼的最后一根稻草。

第三个心得：留一个"验证片段"的习惯。正式长录之前，先录30秒到1分钟，用公式正算加反推验证一遍，确认参数和体积都对得上，再开始长录。这个习惯帮我避免过好几次整场录制报废的事故，成本极低，收益极高。

第四个心得：文档里写清楚计算口径。是1GB=1000^3还是1024^3，帧率用的精确值还是近似值，位深是分量级还是像素级，这些口径不写清楚，团队里不同人算出来的数对不上，沟通成本很高。我现在做容量规划文档，第一页就把口径和公式写死，后面所有人按同一口径算。

5. 从计算到决策：参数选型背后的成本权衡

5.1 为什么专业流程宁愿承受大数据量

看到前面的数字，很多人第一反应是"为什么不压缩"。答案在于未压缩数据在专业流程里的不可替代性。未压缩意味着每一帧都是完整的原始信息，没有编码损失，没有帧间依赖，可以任意跳帧、任意剪辑、任意调色而不产生代际损失。压缩视频每解码再编码一次就损失一次，多代之后画质明显下降。所以在采集、母版存档、高质量调色这些环节，未压缩或者高质量中间格式是刚需，数据量大是必须承受的代价。

理解了这一点，计算方式的意义就变了：它不是为了"省"，而是为了"准"。准了才能合理配置存储和带宽，才能让整个流程稳定跑起来。把数据量算准，然后老老实实配够硬件，比算少了再到处救火要省心得多。我在一个调色工作站项目里，就是按10bit 4:4:4的规格把存储和带宽一次配足，整个项目周期没出过一次因为存储或带宽导致的问题，前期多花的钱远少于后期救火的成本。

5.2 什么场景可以降规格，降了省多少

当然不是所有场景都需要顶格配置。监控存档、内部审片、网络分发这些场景，对画质的要求没那么极致，降规格是合理的。降规格的省法有几种：降色度采样从4:4:4到4:2:2省三分之一，再到4:2:0再省四分之一；降位深从10bit到8bit省20%；降帧率从60到30省一半；降分辨率从4K到1080p省四分之三。这些省法可以叠加，但要注意叠加后的画质损失是否可接受。

给个具体对比：4K60 4:4:4 10bit约2.49GB/s，降到4K30 4:2:0 8bit约373MB/s，省了约85%。这个降幅在监控场景完全可接受，在调色场景就不可接受了。所以降规格的前提是明确场景需求，别一刀切。我的做法是先按最高需求算一个"上限"，再按实际场景算一个"实际配置"，两个数都写进文档，让决策者清楚知道省了什么、牺牲了什么。

5.3 计算方式在采购和验收中的实际用法

最后说一个很实用的场景：采购和验收。买存储设备、买采集卡、买传输链路，供应商给的参数往往是理想值，用计算方式可以快速判断是否满足需求。比如供应商说某采集卡支持4K60 4:2:2 10bit，你就用公式算出需要约1.2GB/s的持续写入能力，然后问供应商这个卡在实际持续写入下的表现，而不是只看接口标称带宽。验收时录一段验证片段，正算反推对一遍，参数和体积都对得上才算过关。

这个用法把计算方式从"纸面公式"变成了"验收工具"，价值很直接。我现在的习惯是任何涉及未压缩视频的采购，都先算清楚需求数据量，再拿这个数去卡供应商的参数，能过滤掉不少虚标或者参数好看但实际跑不满的产品。

6. 把公式变成肌肉记忆：几个快速估算技巧

6.1 心算近似法：30秒内估出量级

实际工作中经常需要快速估个量级，不需要精确到字节。我的心算方法是：记住1080p30 4:2:0 8bit约93MB/s这个基准，然后按比例缩放。分辨率翻倍（像素数四倍）乘4，帧率翻倍乘2，位深8到10乘1.25，采样4:2:0到4:2:2乘1.33（2除以1.5），到4:4:4乘2。这些系数乘起来就是相对基准的倍数。

举例：4K30 4:2:0 8bit，相对1080p30是分辨率四倍，所以约93×4=372MB/s，和表格里的373MB/s几乎一致。4K60 4:2:2 10bit，四倍分辨率乘二倍帧率乘1.25位深乘1.33采样，约93×4×2×1.25×1.33≈1237MB/s，和表格的1244MB/s吻合。这个方法练几次就能在30秒内估出量级，足够支撑现场决策。

6.2 用"每帧字节数"做中间量

另一个好用的中间量是每帧字节数。1080p 4:2:0 8bit每帧约3.1MB，4K同规格每帧约12.4MB，记住这两个数，乘以帧率就是每秒数据量，乘以总帧数就是总体积。用每帧字节数做中间量的好处是，遇到变帧率或者需要按帧数精确计算时特别方便，不用先算每秒再乘时长。

每帧字节数的算法就是宽×高×位深×平均分量数÷8，和每秒公式只差一个帧率因子。把它单独拎出来记，是因为很多实际场景是按帧操作的，比如逐帧处理、按帧缓存、按帧传输，这时候每帧字节数比每秒数据量更直接。

6.3 建立自己的参数速查卡

最后建议每个经常跟未压缩视频打交道的人，建一张自己的参数速查卡，把常用规格的每秒数据量、每小时数据量、每帧字节数都列上，贴在工位或者存成便签。用的时候直接查，比每次套公式快，也比在线计算器可靠（在线计算器有的口径不对，有的采样因子写错）。速查卡的内容可以按自己的项目常用规格定制，比如做监控的就列各种分辨率的4:2:0组合，做影视的就列4:2:2和4:4:4的组合。

这张卡的价值在于把计算变成条件反射，减少现场决策的认知负担。我自己的卡上还标注了每种规格对应的存储持续写入要求和网络带宽要求，一眼就能看出某个规格在当前硬件下能不能跑，非常实用。参数会变，项目会变，但这套计算逻辑和速查的习惯，是可以一直用下去的。