视频数据量算不准项目还没上线硬盘就先红了这种亏我在早期做视频采集和转码流水线的时候吃过不止一次。未压缩视频数据计算方式这件事看起来只是乘几个数的小学算术但真正落到工程里帧率、色深、采样格式、音频轨道、容器开销、对齐填充每一项都能让最终结果差出几十个百分点。我见过有人按“分辨率乘帧率乘3”估容量结果实际写入量翻了一倍多也见过有人把10bit素材当8bit算整条存储方案推倒重来。这篇内容就是把这个计算方式彻底拆开讲清楚它是什么、能解决什么问题、适合谁参考。简单说未压缩视频数据计算就是在一个像素都没有被压缩编码的前提下推算一段视频在内存或存储中占用的原始字节数。它解决的是容量预估、带宽规划、缓存设计、采集卡选型这几类问题。适合做视频采集、监控存储、影视后期、图像算法、嵌入式显示、流媒体服务端的朋友看哪怕你只是想知道一段4K素材到底多大也能直接抄走公式和表格。1. 先把计算模型搭起来为什么不能只乘三个数1.1 未压缩视频的本质是一串像素样本很多人对视频数据量的直觉来自图片一张图多大乘帧率乘时长就完了。这个思路方向没错但漏掉了最关键的一层——视频的每一个像素并不是一个数而是一组分量样本。RGB格式下每个像素有红绿蓝三个分量YUV格式下有一个亮度分量加两个色度分量色度还可能被降采样。所以计算的最小单位不是“像素”而是“样本”。我习惯用一个统一的模型来描述单帧字节数 宽 × 高 × 每像素样本数 × 每样本字节数这里的“每像素样本数”由采样格式决定“每样本字节数”由位深决定。把这两个变量拆开后面所有格式的差异都能套进同一个框架不会算乱。比如RGB24每像素3个样本每样本1字节YUV420 8bit平均每像素1.5个样本每样本1字节YUV422 10bit平均每像素2个样本每样本占2字节实际存储常按16bit对齐。这个模型的价值在于它把“格式”和“位深”解耦了。你换采样格式只动样本数换位深只动字节数两个维度互不干扰排查算错的时候一眼就能定位是哪一层出的问题。1.2 帧率、时长与总数据量的关系单帧算对之后总量就是乘法总字节数 单帧字节数 × 帧率 × 时长秒听起来简单但这里有两个坑。第一帧率不一定是整数29.97、23.976这类值在广播和影视里非常常见用30或24去算会带来千分之几的偏差短片段无所谓长素材累积起来就明显了。第二时长要按实际帧数算而不是按秒四舍五入。一段标称10秒的29.97fps素材实际可能是300帧而不是299或301帧工程上更稳妥的做法是先确定总帧数再乘单帧字节数。我一般建议在正式估算前先把这几个参数固定下来做成一张表分辨率、采样格式、位深、帧率用分数表示更准、总帧数。参数定死之后再套公式避免边算边改导致前后不一致。1.3 为什么工程上还要加“对齐”和“开销”纯理论计算得到的是有效像素数据量但实际写入内存或文件时往往还有额外部分。内存里存在行对齐比如某些硬件要求每行字节数是64或256的整数倍宽度不是整数倍时每行末尾要填充文件里存在容器头、索引、时间戳等元数据开销音频轨道如果一起封装还要加上音频数据量。这些开销在短视频里占比可能很小但在高帧率、高位深、长时间录制的场景下对齐填充能占到几个百分点。所以我的经验是理论值算完之后工程预估再乘一个1.02到1.05的系数具体看平台对齐要求和容器格式。这个系数不是拍脑袋而是根据实际写入日志反推出来的经验区间。2. 采样格式与位深决定数据量的两个核心变量2.1 RGB与YUV的样本数差异RGB是最直观的格式每个像素三个分量样本数就是3。YUV则利用了人眼对亮度敏感、对色度不敏感的特性把色度做了降采样从而减少样本数。常见的几种采样格式平均每像素样本数差别很大采样格式每像素样本数平均说明RGB / YUV4443全采样无色度损失YUV4222水平方向色度减半YUV4201.5水平和垂直方向色度都减半灰度1只有亮度分量这张表是计算的地基。我见过最常见的错误就是把YUV420当成3个样本去算结果数据量直接高估一倍。反过来把RGB素材按1.5算容量预估就会严重不足上线就爆盘。所以第一步永远是确认素材的真实采样格式别信文件名用工具读出来才算数。YUV420为什么是1.5而不是2因为它是每2×2共4个像素共享一组色度样本4个亮度样本加1组UV2个色度样本总共6个样本对应4个像素平均1.5。这个推导过程理解了就不会记错。2.2 位深如何影响每样本字节数位深决定每个样本用多少位表示。8bit时每样本1字节10bit、12bit、16bit时实际存储通常按16bit2字节对齐因为大多数硬件和内存布局不支持“10bit紧凑打包”的高效随机访问。这里有个容易踩的坑10bit素材的理论信息量是10位但存储占用往往按2字节算如果你按10/81.25倍去估会低估60%。我整理了一个对照关系方便直接查位深理论每样本位数常见存储字节数备注8bit81最紧凑10bit102常按16bit对齐12bit122常按16bit对齐16bit162高精度场景所以同样是YUV4228bit和10bit的数据量差一倍而不是差25%。这个结论我在多个采集项目里反复验证过按对齐字节算出来的值才和实际内存占用吻合。2.3 一个完整的单帧计算示例拿一个具体例子走一遍。1920×1080YUV4208bit每像素样本数1.5每样本1字节所以每像素1.5字节单帧字节数 1920 × 1080 × 1.5 3,110,400字节约2.97MB换成YUV422 10bit每像素样本数2每样本2字节每像素4字节单帧字节数 1920 × 1080 × 4 8,294,400字节约7.91MB同样分辨率后者是前者的2.67倍。这个差距就是格式和位深共同作用的结果也是为什么做容量规划必须先问清楚“什么格式、多少位深”而不是只问“多大分辨率”。3. 从单帧到整段帧率、时长与音频的叠加3.1 帧率取值与总帧数的确定帧率这块我的做法是统一用“总帧数”作为中间量而不是直接用秒。计算流程变成先确定总帧数再乘单帧字节数。总帧数从素材元数据里读或者按时长乘帧率再取整。对于29.97这类非整数帧率用分数2997/100参与计算避免浮点误差累积。举个实际场景一段60秒的1080p YUV420 8bit素材帧率29.97。总帧数约1798帧单帧2.97MB总数据量约5.34GB。如果误用30fps算成1800帧差2帧看似不多但在批量处理上千条素材时误差会被放大到需要额外预留容量的程度。3.2 音频轨道的数据量不能忽略视频文件里往往还有音频。未压缩音频的数据量计算相对简单音频字节数 采样率 × 声道数 × 每样本字节数 × 时长比如48kHz、双声道、16bit每秒就是48000×2×2192000字节约187.5KB/s。一小时约675MB。这个量相比视频不算大但在多轨、高采样率、长时间录制的场景下累加起来也不容忽视。我一般会把音频单独算出来再和视频相加而不是笼统估一个百分比。3.3 容器与对齐开销的工程估算前面提过对齐和容器开销。内存对齐方面如果每行字节数不是硬件要求的整数倍每行末尾会填充。比如宽度1920、YUV420 8bit每行亮度1920字节如果硬件要求256字节对齐1920正好是256的7.5倍不是整数就要补到2048多出128字节每行。1080行下来就是138240字节约0.13MB占单帧的4%左右。这个比例在窄宽度素材上会更明显。容器开销则取决于封装格式头部、索引、每帧时间戳都会占空间。我的经验系数是视频有效数据乘1.02到1.05音频和元数据另算。这个系数一定要用实际写入日志校准一次不同平台差异不小。4. 实操流程一套可以直接复用的计算脚本4.1 参数录入与单位统一手工算容易出错我习惯写一个小脚本把流程固化下来。核心是把所有参数统一到“字节”和“帧”两个单位避免MB、GB、秒、帧混用。下面是一个Python示例输入分辨率、采样格式、位深、帧率、时长输出理论数据量和含开销的工程预估值def calc_uncompressed_video(width, height, samples_per_pixel, bytes_per_sample, fps, duration_sec, overhead1.03): frame_bytes width * height * samples_per_pixel * bytes_per_sample total_frames round(fps * duration_sec) video_bytes frame_bytes * total_frames estimated video_bytes * overhead return { frame_bytes: frame_bytes, total_frames: total_frames, video_bytes: video_bytes, estimated_bytes: estimated, estimated_gb: estimated / (1024**3) } # 1920x1080 YUV420 8bit 29.97fps 60秒 print(calc_uncompressed_video(1920, 1080, 1.5, 1, 29.97, 60))这个脚本的好处是把“理论值”和“工程预估值”分开输出方便对照。overhead参数默认1.03实际项目里根据平台对齐要求调整。4.2 用实际素材校验计算结果脚本算完不能直接用必须拿一段真实素材校验。方法是录制或生成一段已知参数的未压缩素材用系统工具查看实际文件大小或内存占用和脚本结果对比。偏差在5%以内说明参数选对了偏差大就要回头检查采样格式、位深对齐、帧率取值。我踩过的一个坑是某平台导出的“未压缩”素材其实带了轻量封装和填充实际大小比理论值高8%。如果不校验直接按理论值规划存储批量任务就会在后期爆盘。所以校验这一步不能省它是把公式落到实地上的关键。4.3 批量场景下的容量规划表单条素材算清楚之后批量场景要做汇总。我一般做一张规划表列出每条素材的参数、单帧大小、总帧数、单条总量最后求和并留出余量。下面是一个简化示例素材分辨率格式位深帧率时长单条预估A1920×1080YUV420829.9760s5.5GBB3840×2160YUV422102530s23.7GBC1280×720RGB830120s24.9GB汇总之后按总量的1.1到1.2倍预留存储给对齐、容器、临时文件和并发写入留缓冲。这个余量不是浪费而是工程上必须的安全垫。5. 常见问题与排查技巧实录5.1 算出来和实际差很多先查这三处数据量对不上我通常按顺序查三处第一采样格式是否搞错尤其YUV420被当成3样本第二位深是否按对齐字节算10bit按1.25倍估是高频错误第三帧率是否用了整数近似长素材累积误差明显。这三处覆盖了绝大多数偏差来源。5.2 高频错误速查表现象可能原因排查方法结果偏大一倍YUV420按3样本算确认平均样本数1.5结果偏小六成10bit按1.25倍算改按每样本2字节长素材误差累积帧率取整用分数帧率或总帧数实际写入更大对齐填充与容器开销加1.02~1.05系数并校验5.3 几个容易被忽略的细节第一宽高不一定是偶数某些格式对奇数尺寸有特殊处理计算前先确认。第二多平面格式的平面顺序和对齐可能不同YUV420的Y、U、V三个平面可能各自对齐不能简单按总量算。第三内存带宽和存储容量是两回事容量算对了不代表带宽够高帧率高分辨率场景要单独评估带宽。第四临时文件和缓存也要算进去转码、拼接、预览都会产生额外占用。我在实际项目里的体会是未压缩视频数据计算本身不难难的是把参数确认清楚、把工程开销估准、把校验环节做扎实。公式是死的参数是活的每次新项目我都坚持先拿真实素材跑一遍校验再去做批量规划。最后分享一个小技巧把常用分辨率和格式的单帧大小做成一张速查表贴在工位上临时估算时直接查表乘帧数比每次开脚本快得多也不容易算错。 
长河君 · 2026/11/3 3:50:00 · 阅读 1.2k 未压缩视频数据计算：从原理到工程实践
视频数据量算不准项目还没上线硬盘就先红了这种亏我在早期做视频采集和转码流水线的时候吃过不止一次。未压缩视频数据计算方式这件事看起来只是乘几个数的小学算术但真正落到工程里帧率、色深、采样格式、音频轨道、容器开销、对齐填充每一项都能让最终结果差出几十个百分点。我见过有人按“分辨率乘帧率乘3”估容量结果实际写入量翻了一倍多也见过有人把10bit素材当8bit算整条存储方案推倒重来。这篇内容就是把这个计算方式彻底拆开讲清楚它是什么、能解决什么问题、适合谁参考。简单说未压缩视频数据计算就是在一个像素都没有被压缩编码的前提下推算一段视频在内存或存储中占用的原始字节数。它解决的是容量预估、带宽规划、缓存设计、采集卡选型这几类问题。适合做视频采集、监控存储、影视后期、图像算法、嵌入式显示、流媒体服务端的朋友看哪怕你只是想知道一段4K素材到底多大也能直接抄走公式和表格。1. 先把计算模型搭起来为什么不能只乘三个数1.1 未压缩视频的本质是一串像素样本很多人对视频数据量的直觉来自图片一张图多大乘帧率乘时长就完了。这个思路方向没错但漏掉了最关键的一层——视频的每一个像素并不是一个数而是一组分量样本。RGB格式下每个像素有红绿蓝三个分量YUV格式下有一个亮度分量加两个色度分量色度还可能被降采样。所以计算的最小单位不是“像素”而是“样本”。我习惯用一个统一的模型来描述单帧字节数 宽 × 高 × 每像素样本数 × 每样本字节数这里的“每像素样本数”由采样格式决定“每样本字节数”由位深决定。把这两个变量拆开后面所有格式的差异都能套进同一个框架不会算乱。比如RGB24每像素3个样本每样本1字节YUV420 8bit平均每像素1.5个样本每样本1字节YUV422 10bit平均每像素2个样本每样本占2字节实际存储常按16bit对齐。这个模型的价值在于它把“格式”和“位深”解耦了。你换采样格式只动样本数换位深只动字节数两个维度互不干扰排查算错的时候一眼就能定位是哪一层出的问题。1.2 帧率、时长与总数据量的关系单帧算对之后总量就是乘法总字节数 单帧字节数 × 帧率 × 时长秒听起来简单但这里有两个坑。第一帧率不一定是整数29.97、23.976这类值在广播和影视里非常常见用30或24去算会带来千分之几的偏差短片段无所谓长素材累积起来就明显了。第二时长要按实际帧数算而不是按秒四舍五入。一段标称10秒的29.97fps素材实际可能是300帧而不是299或301帧工程上更稳妥的做法是先确定总帧数再乘单帧字节数。我一般建议在正式估算前先把这几个参数固定下来做成一张表分辨率、采样格式、位深、帧率用分数表示更准、总帧数。参数定死之后再套公式避免边算边改导致前后不一致。1.3 为什么工程上还要加“对齐”和“开销”纯理论计算得到的是有效像素数据量但实际写入内存或文件时往往还有额外部分。内存里存在行对齐比如某些硬件要求每行字节数是64或256的整数倍宽度不是整数倍时每行末尾要填充文件里存在容器头、索引、时间戳等元数据开销音频轨道如果一起封装还要加上音频数据量。这些开销在短视频里占比可能很小但在高帧率、高位深、长时间录制的场景下对齐填充能占到几个百分点。所以我的经验是理论值算完之后工程预估再乘一个1.02到1.05的系数具体看平台对齐要求和容器格式。这个系数不是拍脑袋而是根据实际写入日志反推出来的经验区间。2. 采样格式与位深决定数据量的两个核心变量2.1 RGB与YUV的样本数差异RGB是最直观的格式每个像素三个分量样本数就是3。YUV则利用了人眼对亮度敏感、对色度不敏感的特性把色度做了降采样从而减少样本数。常见的几种采样格式平均每像素样本数差别很大采样格式每像素样本数平均说明RGB / YUV4443全采样无色度损失YUV4222水平方向色度减半YUV4201.5水平和垂直方向色度都减半灰度1只有亮度分量这张表是计算的地基。我见过最常见的错误就是把YUV420当成3个样本去算结果数据量直接高估一倍。反过来把RGB素材按1.5算容量预估就会严重不足上线就爆盘。所以第一步永远是确认素材的真实采样格式别信文件名用工具读出来才算数。YUV420为什么是1.5而不是2因为它是每2×2共4个像素共享一组色度样本4个亮度样本加1组UV2个色度样本总共6个样本对应4个像素平均1.5。这个推导过程理解了就不会记错。2.2 位深如何影响每样本字节数位深决定每个样本用多少位表示。8bit时每样本1字节10bit、12bit、16bit时实际存储通常按16bit2字节对齐因为大多数硬件和内存布局不支持“10bit紧凑打包”的高效随机访问。这里有个容易踩的坑10bit素材的理论信息量是10位但存储占用往往按2字节算如果你按10/81.25倍去估会低估60%。我整理了一个对照关系方便直接查位深理论每样本位数常见存储字节数备注8bit81最紧凑10bit102常按16bit对齐12bit122常按16bit对齐16bit162高精度场景所以同样是YUV4228bit和10bit的数据量差一倍而不是差25%。这个结论我在多个采集项目里反复验证过按对齐字节算出来的值才和实际内存占用吻合。2.3 一个完整的单帧计算示例拿一个具体例子走一遍。1920×1080YUV4208bit每像素样本数1.5每样本1字节所以每像素1.5字节单帧字节数 1920 × 1080 × 1.5 3,110,400字节约2.97MB换成YUV422 10bit每像素样本数2每样本2字节每像素4字节单帧字节数 1920 × 1080 × 4 8,294,400字节约7.91MB同样分辨率后者是前者的2.67倍。这个差距就是格式和位深共同作用的结果也是为什么做容量规划必须先问清楚“什么格式、多少位深”而不是只问“多大分辨率”。3. 从单帧到整段帧率、时长与音频的叠加3.1 帧率取值与总帧数的确定帧率这块我的做法是统一用“总帧数”作为中间量而不是直接用秒。计算流程变成先确定总帧数再乘单帧字节数。总帧数从素材元数据里读或者按时长乘帧率再取整。对于29.97这类非整数帧率用分数2997/100参与计算避免浮点误差累积。举个实际场景一段60秒的1080p YUV420 8bit素材帧率29.97。总帧数约1798帧单帧2.97MB总数据量约5.34GB。如果误用30fps算成1800帧差2帧看似不多但在批量处理上千条素材时误差会被放大到需要额外预留容量的程度。3.2 音频轨道的数据量不能忽略视频文件里往往还有音频。未压缩音频的数据量计算相对简单音频字节数 采样率 × 声道数 × 每样本字节数 × 时长比如48kHz、双声道、16bit每秒就是48000×2×2192000字节约187.5KB/s。一小时约675MB。这个量相比视频不算大但在多轨、高采样率、长时间录制的场景下累加起来也不容忽视。我一般会把音频单独算出来再和视频相加而不是笼统估一个百分比。3.3 容器与对齐开销的工程估算前面提过对齐和容器开销。内存对齐方面如果每行字节数不是硬件要求的整数倍每行末尾会填充。比如宽度1920、YUV420 8bit每行亮度1920字节如果硬件要求256字节对齐1920正好是256的7.5倍不是整数就要补到2048多出128字节每行。1080行下来就是138240字节约0.13MB占单帧的4%左右。这个比例在窄宽度素材上会更明显。容器开销则取决于封装格式头部、索引、每帧时间戳都会占空间。我的经验系数是视频有效数据乘1.02到1.05音频和元数据另算。这个系数一定要用实际写入日志校准一次不同平台差异不小。4. 实操流程一套可以直接复用的计算脚本4.1 参数录入与单位统一手工算容易出错我习惯写一个小脚本把流程固化下来。核心是把所有参数统一到“字节”和“帧”两个单位避免MB、GB、秒、帧混用。下面是一个Python示例输入分辨率、采样格式、位深、帧率、时长输出理论数据量和含开销的工程预估值def calc_uncompressed_video(width, height, samples_per_pixel, bytes_per_sample, fps, duration_sec, overhead1.03): frame_bytes width * height * samples_per_pixel * bytes_per_sample total_frames round(fps * duration_sec) video_bytes frame_bytes * total_frames estimated video_bytes * overhead return { frame_bytes: frame_bytes, total_frames: total_frames, video_bytes: video_bytes, estimated_bytes: estimated, estimated_gb: estimated / (1024**3) } # 1920x1080 YUV420 8bit 29.97fps 60秒 print(calc_uncompressed_video(1920, 1080, 1.5, 1, 29.97, 60))这个脚本的好处是把“理论值”和“工程预估值”分开输出方便对照。overhead参数默认1.03实际项目里根据平台对齐要求调整。4.2 用实际素材校验计算结果脚本算完不能直接用必须拿一段真实素材校验。方法是录制或生成一段已知参数的未压缩素材用系统工具查看实际文件大小或内存占用和脚本结果对比。偏差在5%以内说明参数选对了偏差大就要回头检查采样格式、位深对齐、帧率取值。我踩过的一个坑是某平台导出的“未压缩”素材其实带了轻量封装和填充实际大小比理论值高8%。如果不校验直接按理论值规划存储批量任务就会在后期爆盘。所以校验这一步不能省它是把公式落到实地上的关键。4.3 批量场景下的容量规划表单条素材算清楚之后批量场景要做汇总。我一般做一张规划表列出每条素材的参数、单帧大小、总帧数、单条总量最后求和并留出余量。下面是一个简化示例素材分辨率格式位深帧率时长单条预估A1920×1080YUV420829.9760s5.5GBB3840×2160YUV422102530s23.7GBC1280×720RGB830120s24.9GB汇总之后按总量的1.1到1.2倍预留存储给对齐、容器、临时文件和并发写入留缓冲。这个余量不是浪费而是工程上必须的安全垫。5. 常见问题与排查技巧实录5.1 算出来和实际差很多先查这三处数据量对不上我通常按顺序查三处第一采样格式是否搞错尤其YUV420被当成3样本第二位深是否按对齐字节算10bit按1.25倍估是高频错误第三帧率是否用了整数近似长素材累积误差明显。这三处覆盖了绝大多数偏差来源。5.2 高频错误速查表现象可能原因排查方法结果偏大一倍YUV420按3样本算确认平均样本数1.5结果偏小六成10bit按1.25倍算改按每样本2字节长素材误差累积帧率取整用分数帧率或总帧数实际写入更大对齐填充与容器开销加1.02~1.05系数并校验5.3 几个容易被忽略的细节第一宽高不一定是偶数某些格式对奇数尺寸有特殊处理计算前先确认。第二多平面格式的平面顺序和对齐可能不同YUV420的Y、U、V三个平面可能各自对齐不能简单按总量算。第三内存带宽和存储容量是两回事容量算对了不代表带宽够高帧率高分辨率场景要单独评估带宽。第四临时文件和缓存也要算进去转码、拼接、预览都会产生额外占用。我在实际项目里的体会是未压缩视频数据计算本身不难难的是把参数确认清楚、把工程开销估准、把校验环节做扎实。公式是死的参数是活的每次新项目我都坚持先拿真实素材跑一遍校验再去做批量规划。最后分享一个小技巧把常用分辨率和格式的单帧大小做成一张速查表贴在工位上临时估算时直接查表乘帧数比每次开脚本快得多也不容易算错。