4K 120fps原始视频数据集与编码评测指南

简介：围绕UVG 4K视频数据集展开的技术论文，面向视频编码研究者、算法工程师及高校相关专业学生，服务于高帧率超高清测试序列的选型、编解码评测与开发验证。文中系统介绍Ultra Video Group公开的16个3840×2160自然序列，覆盖50 fps与120 fps、8位和10位4:2:0 YUV格式，并说明其由Sony F65拍摄转换及非商业CC BY-NC许可，进而分析空间与时间感知信息、率失真行为及编码复杂度。作者还将这些序列与HEVC/H.265、VVC/H.266参考编解码器进行对比，指出其对下一代VVC主观和客观质量评估的补充意义。压缩包内为1个PDF文件，约931KB，便于直接查阅数据集构成、序列特征与实验结论。已有142人学习，可作为4K视频编码研究、测试集搭建和性能分析的参考，帮助读者把握高帧率序列的评测维度、数据集选用依据以及率失真与复杂度分析思路。

1. 4K 高帧率视频数据集：同一段素材，换个测试集结论就反了

调过视频编码参数的人大多踩过这样的坑：同一套码率控制策略，在这段素材上省了 8% 码率，换一段素材反而多花 3%。问题常常不在算法，而在"拿什么素材测"。这就像评判两把菜刀谁更锋利，却一会儿切冻肉一会儿切豆腐，结论全靠运气。

4K 视频数据集就是给这件事定规矩的东西：一批分辨率、帧率、色彩格式都统一的原始 4K 素材，专门喂给视频编码器做横向对比。UVG 4K 视频数据集比较特别的地方在于把帧率推到了 120fps——16 段 3840×2160 的原始序列，8 段 120fps、8 段 50fps，每段都是 600 帧，同时提供 8bit 和 10bit 的 4:2:0 YUV 版本。搞懂它为什么这么设计，比背下参数有用得多。

2. 为什么非得用原始视频：编码器评测里的"标准试纸"

2.1 率失真曲线：比的从来不是"谁压得小"

把一段 4K 视频压到十分之一大小，任何编码器都能做到，难的是压完之后画面还能不能看。所以视频编码领域衡量一个编码器，从来不看单一数字，而是看一对数字：码率和质量。把同一段素材用几档不同的量化强度各压一遍，每一档记录下"花了多少码率"和"画质掉了多少"，把这些点连起来，就得到一条率失真曲线，业内简称 RD 曲线。

RD 曲线是编码器评测的基本语言。两个编码器对比，看的不是某一档谁码率低，而是整条曲线谁在上面：同样画质下谁更省码率，或者同样码率下谁画质更好。这条曲线上的差距，通常换算成一个百分比，叫 BD-rate，意思是"在相同画质前提下平均节省了多少码率"。省 5% 和 15% 在论文里是天壤之别，而这两个数字能不能站得住，全看你用的是哪批素材。

这就引出第一个硬要求：素材必须能让不同编码器的差距稳定暴露出来。太简单的素材，比如大面积纯色墙面，所有编码器都轻松搞定，曲线挤在一起看不出差别；太复杂的素材又会让所有编码器都崩盘，同样分不出高下。真正有价值的是那些处在中间地带、又覆盖多种内容类型的素材。这也是为什么一个数据集里要放十几段不同场景，而不是随便找一段风景。

还有一层容易忽略的：一档量化参数画不出曲线。至少需要四到五个码率点，才能拟合出稳定的曲线，进而算出可信的 BD-rate。这意味着同一个素材要被反复编码十几次甚至几十次，数据集本身的规模和可获取性直接决定了实验能不能做完。

2.2 已经压过的素材，会把别人的毛病算到自己头上

很多人第一次做编码实验，会顺手从网上抓几个现成的 4K 视频文件当测试素材。这样做的结果，往往是数据很好看，但结论不可信。

原因在于代际损失。一个已经用某种编码器压过的视频，画面里早就布满了那个编码器留下的痕迹：块效应、振铃、色带、模糊的边缘。你再用自己的编码器去压它，压的其实是"别人压缩后的残渣"，而不是真实世界的画面。这时候你的编码器表现好，可能只是因为它擅长处理这类残渣；表现差，可能只是因为它被前任编码器的伪影带偏了。更麻烦的是这种误差不可控，你甚至不知道自己测的是编码器还是两个编码器的化学反应。

打个比方，这就像测复印机的清晰度，却拿一张已经复印过三遍的纸当原稿。你测出来的是这台复印机对模糊图像的处理能力，不是它对真实照片的还原能力。

原始视频（raw video）解决的正是这个问题。它没有经过任何有损压缩，每一帧都是传感器采下来的原始数值，不存在前任编码器留下的痕迹。你压它，得到的失真就纯粹是你自己造成的。代价也很直接：原始 4K 素材极其占空间，一段 600 帧的 8bit 4:2:0 序列大约 7GB，10bit 版本翻倍到 14GB 左右，整个数据集铺开是几百 GB 的量级。这个体积决定了原始素材几乎不可能靠个人随手采集攒齐，必须由专门的团队用专业设备拍摄、转码、整理、长期在线提供。

顺带说清一个边界：加工过的成片数据集并非没有价值，它们在体验质量评估、转码链路测试、传输码流分析里非常好用，因为这些场景本来面对的就是已经是压缩过的视频。但只要你研究的是编码器本身，就必须回到原始数据。

2.3 120fps 补上的是时间维度的空白

过去十来年的 4K 公共测试集，帧率基本集中在 30fps 到 60fps 之间。这个区间对应的是传统影视和广播电视的内容节奏，用它们评测为广播设计的编码器，没什么问题。

但现在的内容形态变了。高帧率拍摄不再是小众玩法，慢动作回放、体育转播、游戏录屏、高刷新率屏幕上的内容，都在把帧率往上推。编码器面对 120fps 时的工作方式和 30fps 完全不是一回事：相邻帧之间的时间间隔缩短到原来的四分之一，物体位移变小，运动补偿的搜索范围、参考帧的选择策略、帧间预测的收益都会跟着变。有些在 30fps 下表现优秀的快速算法，到了 120fps 可能因为运动矢量分布变化而收益锐减；也有些在低帧率下看不出来的问题，在高帧率下被放大。

更实际的一点是码率。帧率翻四倍，帧数翻四倍，即便每帧压得更狠，总码率通常还是显著上升。高帧率内容对码率控制和缓冲区管理是全新压力。如果测试集里一段 120fps 的素材都没有，这些压力根本测不出来。

有读者可能会问：要测高帧率，把 50fps 的素材隔帧复制一份插上去不就行了？不行。这种"伪造高帧率"的做法会让相邻帧几乎完全一样，帧间预测变得异常简单，编码器轻松拿到不真实的增益，测出来的 RD 曲线是假的。真实的高帧率素材必须真的以 120fps 采集，每一帧都有真实的、微小的运动差异。这也是这个数据集明确强调"原生 120fps 拍摄"的原因。

2.4 一段素材不够：过拟合到素材本身

算法研究里有个反复出现的现象：某个改进在单一测试序列上效果拔群，换一段就归零。这不是算法没用，而是它恰好适配了那段素材的某种统计特性，比如特定的纹理方向、特定的运动速度、特定的亮度分布。

要压住这种过拟合，唯一的办法是让测试集在内容维度上足够分散：有慢镜头也有高速运动，有平滑渐变也有密集细节，有高对比也有低对比，有顺光也有逆光。数据集作者在整理这 16 段素材时，恰恰是按这套维度一个个登记特征的——运动快慢、纹理繁简、对比高低，每段都标清楚。这种"带标注的多样性"比单纯堆数量有用得多，因为它让你在实验结果异常时能快速定位：是慢速场景出了问题，还是高纹理场景出了问题。

3. 这 16 段素材到底拍了什么：内容、SI/TI 与三个格式参数

3.1 两条主线：一半慢镜，一半高速

16 段序列按帧率对半分。120fps 的那 8 段每段 5 秒、600 帧；50fps 的那 8 段每段 12 秒、600 帧。帧数统一在 600 是个很实用的设计——横向比较时不需要做帧数对齐，跑完直接比总码率、总耗时就行，少了一堆预处理脚本。

内容上，这 16 段覆盖了人像、水面、城市街景、花田、昆虫、赛马、夜景等场景。资料里对每段都给了运动、纹理、对比度三个标签，下面挑出有明确记录的部分序列：

表里"运动元素多"和"运动快"是两个不同维度，这点值得展开说一下。HoneyBee 标的是"快 / 少"：镜头固定对准花心，蜜蜂在画面中间高速飞，背景几乎静止——运动集中在很小的区域，但速度极快，帧间位移大。FlorKids 标的是"慢 / 多"：镜头整体移动很慢，但画面里有孩子跑动、相机轻微抖动、背景还有阳光造成的眩光，运动元素散布在全画面。对编码器来说，这两种情况考验的能力完全不同：前者考的是小范围大位移的运动估计，后者考的是全局运动与局部运动的混合建模。

再看 Jockey，赛马题材，镜头跟拍，主体清晰而背景高速掠过，焦点还会从骑手切到马腿。这种"背景整体平移 + 焦点变化"的组合，是运动补偿算法最容易翻车的场景之一。而像 Bosphorus 这种雾蒙蒙的水面加远山，细节被雾气抹平，纹理看着复杂其实能量很低，反而是低对比度、低纹理能量的代表，测的是编码器会不会在平坦区域浪费码率。

把这些组合摊开看，就能明白数据集的意图：不是拍 16 段好看的风景，而是覆盖编码器可能遇到的 16 种难缠情形。

3.2 SI 与 TI：把"细节多"和"动得快"变成两个数

"这段素材纹理复杂"是主观判断，不同人看法不同，写成论文没法复现。所以业界沿用了两个经典指标，把这件主观的事量化：空间感知信息 SI 和时间感知信息 TI。

SI 衡量单帧画面里有多少空间细节。做法是：把每一帧的亮度分量拿去做 Sobel 边缘检测，得到每个像素的梯度幅值，再对这一帧所有梯度值求标准差，最后取整段视频里最大的那个标准差。标准差越大，说明画面里明暗跳变越剧烈、边缘越密集，空间细节越丰富。公式写出来是这样：

SI = max over n of { std[ sqrt(Gh(i,j)^2 + Gv(i,j)^2) ] }

其中 Gh 和 Gv 分别是水平方向和垂直方向的 3×3 Sobel 卷积结果，i、j 遍历帧内像素，n 遍历所有帧。

TI 衡量的是时间方向上的变化量。做法更简单：把相邻两帧逐像素相减，对差值求标准差，同样取整段视频里的最大值。

TI = max over n of { std[ F(n,i,j) - F(n-1,i,j) ] }

这两个值一起用，就能把一段素材定位到一张二维散点图上：横轴 SI、纵轴 TI。好的测试集应该在这张图上铺得足够开——左下角是又平又静的镜头，右上角是又快又碎的镜头，中间还有各种组合。如果你手上的测试集全挤在左下角，那测出来的结论只能代表"省流场景"，推广到高速运动内容上多半会出问题。

提示：SI 和 TI 都是取全片最大值，所以一段 12 秒的素材里只要有一帧特别花，SI 就会很高。看指标时最好结合片段实际内容，别只看数字下结论。

这两个指标还有个实用场景：拿新数据集和你一直用的老测试集各画一张 SI-TI 散点图，叠在一起看覆盖范围。如果新数据集的点大部分落在老测试集没覆盖的区域，说明它补的是空白，值得加进评测；如果高度重合，那换不换意义不大。资料里把自己和主流 4K 标准测试集做过这类对比，结论是覆盖面互补，而不是简单重复。

3.3 8bit、10bit 与 4:2:0：三个常被跳过的参数

拿到一个 .yuv 文件，如果不知道三个参数，基本等于拿到一块没有说明书的外置硬盘。这三个参数是分辨率、位深、色度采样格式，这份数据集里分别是 3840×2160、8 或 10bit、4:2:0。

4:2:0 说的是色度抽样。人眼对亮度远比对颜色敏感，所以视频编码普遍把亮度分量完整保留，色度分量在水平和垂直方向各减半。一个 4:2:0 的 8bit 帧，总数据量是像素数的 1.5 倍字节，不是 3 倍。3840×2160 乘 1.5，单帧约 12MB，600 帧就是 7GB 出头。这也解释了为什么原始素材这么吃硬盘。

10bit 的意义不只是"颜色更多"。8bit 每个通道只有 256 个取值，在天空、渐变墙面这类平滑区域，量化台阶很容易被看出来，形成一条条色带。10bit 把取值扩到 1024 级，量化台阶变细，色带问题大幅缓解。更关键的是对编码本身的影响：量化步长在更细的精度上划分，残差分布更集中，同样的主观画质下往往能省下可观的码率。所以现代编码器评测基本都在 10bit 下跑，8bit 版本更多用于兼容性测试和对比实验。

注意：10bit 的 YUV 文件通常每个样本占 2 字节存放，有效位只有 10 位，剩下的位是填充。所以文件体积是 8bit 的两倍，而不是 1.25 倍。

除了这三个参数，还有个隐含条件：YUV 是裸数据，没有容器、没有文件头、没有时间戳。播放器不知道它多大、多快、多少帧，必须由你手动告诉它。这一点在下一章会具体演示，也是新手最常卡住的地方。

4. 常见误区与易混概念：4K 不等于清楚，120fps 不等于流畅

4.1 误区一：4K 数据集就等于高画质素材

易混点：把"分辨率"当成"画质"的同义词，看到 3840×2160 就默认这批素材质量极高。

为什么混：手机和电视的营销话术把 4K 和"清晰"绑死了，久而久之 4K 变成了形容词。但对编码研究来说，4K 只是一个尺寸标签——它告诉你每帧有 830 万个像素点要处理，不告诉你这些像素点拍的是什么。

怎么区分：画质取决于拍摄条件、光照、镜头、噪点控制，分辨率只决定信息量的上限。这批素材里有高对比的清晰人像，也有雾气弥漫、细节被抹平的水面镜头，两者的"观感清晰度"差得很远，但分辨率都是 4K。评测时真正要关心的是 SI/TI 落在哪个区间、纹理是复杂还是平滑，而不是分辨率数字。

4.2 误区二：YUV 文件就是视频文件

易混点：把 .yuv 和 .mp4 当成同一类东西，双击打不开就以为文件坏了。

为什么混：日常语境里"视频"就是能在播放器里拖进度条的文件，而 .yuv 没有容器，播放器无从下手。

怎么区分：.mp4 是"容器 + 编码后的码流"，文件里带着索引、时间戳、编码参数，解码器能自己读懂；.yuv 是"裸像素流"，只有一连串 Y、U、V 数值首尾相接，没有任何元信息。打开它必须手工指定像素格式、分辨率、帧率。更进一步，.mp4 里存的是压缩后的数据，.yuv 存的是压缩前的数据，两者在编码流程里处于完全相反的两端。

4.3 误区三：帧率越高画质越好

易混点：看到 120fps 就以为画质优于 50fps。

为什么混：游戏和显示器的宣传把高帧率和"丝滑"绑定，容易让人以为高帧率是全面升级。

怎么区分：帧率影响的是时间维度的连续性，不是单帧的清晰度。120fps 的价值在于运动更连贯、慢放时有更多真实帧可用，但每帧本身的空间细节和 50fps 素材没有必然关系。更重要的是，帧率翻倍意味着每秒要编码的帧数翻倍，在码率固定的前提下，每帧能分到的比特反而更少，单帧质量可能下降。高帧率换来的是流畅，付出的是码率，这是笔要算清楚的账。

4.4 误区四：8bit 和 10bit 的差别只是颜色数量

易混点：以为 10bit 就是"颜色更丰富"，在普通显示器上看不出区别所以觉得没必要。

为什么混：8bit 每通道 256 级、10bit 每通道 1024 级，这个数字对比确实容易让人只想到"颜色多"。

怎么区分：颜色数量的提升只是表面，真正起作用的是量化精度。在平滑渐变区域，8bit 的量化台阶会造成可见色带，10bit 则把台阶压到肉眼阈值以下。对编码器而言，10bit 输入的残差信号更精细，压缩效率通常更高。所以哪怕最终显示设备只有 8bit，用 10bit 做中间处理仍然有价值——差别不在"看到多少颜色"，而在"压缩时少了多少粗暴的取整"。

4.5 误区五：客观指标好，人眼看就一定舒服

易混点：把 PSNR、SSIM 这类数值当成画质的最终裁判。

为什么混：这些指标算起来方便、可复现、能画曲线，用久了容易忘记它们只是代理。

怎么区分：PSNR 只看逐像素误差，对"整体模糊但每个像素差得不多"和"大部分区域完全一致但局部严重损坏"给出的分数可能差不多，而人眼对这两者的感受天差地别。SSIM 考虑了结构相似性，好一些，但在高压缩比、强纹理区域仍会失准。更贴近主观感受的指标（比如基于学习的质量评价模型）计算成本高，也没到可以完全替代人眼的程度。稳妥做法是：客观指标做主筛，关键结论必须配一轮主观观看验证。

5. 拿到数据集怎么跑：一次最小可信的编码评测

5.1 先把读取参数对齐

原始 YUV 文件没有元信息，第一步永远是告诉工具它是谁。以一段 120fps、10bit、4:2:0 的序列为例，先确认能正常播放：

# 参数说明 # -f rawvideo 输入是裸视频流，不是容器 # -pixel_format 10bit 4:2:0 对应 yuv420p10le，8bit 则是 yuv420p # -video_size 分辨率，这份数据集固定 3840x2160 # -framerate 源帧率，120fps 与 50fps 要分开指定 ffplay -f rawvideo \ -pixel_format yuv420p10le \ -video_size 3840x2160 \ -framerate 120 \ 序列名_3840x2160_120fps_10bit_420.yuv

命令行里的文件名按你实际下载到的替换，重点在四个参数：像素格式、分辨率、帧率、位深。少给一个，播放器要么报错，要么给你放出一堆错位的花屏。如果画面出现颜色错乱但形状正常，八成是像素格式写错了（把 10bit 当 8bit 读）；如果画面像被斜着切了一刀，多半是分辨率不对。

注意：8bit 和 10bit 的文件体积差一倍，但分辨率帧率完全一样，靠文件大小能快速判断自己下的是哪个版本。

5.2 编一遍、量一遍：最小闭环

一次完整的评测包含三步：编码、解码、比对。先用编码器把原始 YUV 压成码流，记录码率和编码耗时；再把码流解回 YUV；最后拿解码结果和原始 YUV 逐帧比对，算质量指标。

比对这一步用现成工具就能做，不需要自己写：

# 把原始序列和解码后序列逐帧比对，输出 PSNR # 两个输入的像素格式、分辨率、帧率必须完全一致，否则比对无意义 ffmpeg -f rawvideo -pixel_format yuv420p10le -video_size 3840x2160 -framerate 120 \ -i 原始序列.yuv \ -f rawvideo -pixel_format yuv420p10le -video_size 3840x2160 -framerate 120 \ -i 解码后序列.yuv \ -lavfi psnr -f null -

输出里会有每一帧的 PSNR 和整段的平均值。把平均值连同这一档的码率记下来，就得到了 RD 曲线上的一个点。

一个点不够。至少跑四到五档量化强度，比如从很轻的压缩到很重的压缩，得到四五个（码率，PSNR）坐标，才能拟合出稳定曲线。每一档都要重复"编码 → 解码 → 比对"这套流程。如果还要和其他编码器比，就把这套流程在两边各跑一遍，然后算 BD-rate。这个计算有现成脚本，输入两组码率-质量点即可，不必手推积分。

容易被忽略的是：比对必须用解码后的序列，不能用编码器内部的重建帧。有些编码器内部的重建帧和最终输出的解码结果存在细微差异（尤其是开启某些优化选项后），拿内部帧算指标会得到偏乐观的结果，等别人复现时对不上，就变成了那种说不清道不明的玄学问题。

5.3 复杂度与可复现性：时间不是唯一指标

编码复杂度常被简化成"跑得多快"，但真正要记录的东西至少有三项：编码耗时、解码耗时、内存峰值。

编码耗时最直观，但也最容易被环境干扰。同一份码，跑在三台机器上能差出三倍。要让数字有意义，必须固定几个条件：线程数写死，不要让它随 CPU 核心数自动变；关掉硬件加速，纯软件跑；记录 CPU 型号和主频；最好连编译选项一起写进实验记录。血泪经验是：改了一行代码想对比前后差异，结果发现是后台同步在占 CPU，白跑一晚上。

解码耗时对实际产品更关键。很多场景（比如移动端播放、实时通信）瓶颈不在编码端而在解码端，编码省了 10% 码率但解码慢了 30%，整体体验是倒退的。所以一个负责任的评测报告里，编码和解码的复杂度应该分开列。

内存峰值则直接决定能不能落地到嵌入式设备。4K 10bit 的单帧裸数据就有二十多兆，参考帧缓冲、运动估计的搜索窗口、变换块的临时存储，层层叠加后很容易吃掉几百兆。这个数字不测出来，方案在纸面上再漂亮也装不进目标设备。

提示：跑复杂度实验前，先把系统调到性能模式，关掉自动更新和同步服务，跑三轮取中位数。单轮数据不要直接写进结论。

5.4 先用两三段做筛选，再铺开全量

16 段素材全量跑一遍，按每段多档量化、每个量化跑编码解码比对来算，几十小时是常态。如果每改一版算法就全量重跑，时间根本不够用。

合理做法是分层筛选。从 SI-TI 散点图上挑三段代表：一段低 SI 低 TI（平坦安静）、一段高 SI 低 TI（细节密集但运动少）、一段高 TI（运动剧烈）。这三段能覆盖大部分失效模式——算法在平坦区浪费码率、在纹理区丢细节、在运动区预测失效，三种毛病各有对应的试纸。三段都过了，再铺到 8 段，最后全量。

筛选阶段还有个技巧：用短片段。600 帧里取前 120 帧跑一轮，趋势基本能看出来，成本只有五分之一。趋势不对就立刻回头改，不要抱着"说不定全量跑完就好了"的侥幸——通常不会好。

6. 什么时候该用它，什么时候别用

判断一份素材适不适合自己，最省事的办法是先问一句：我要验证的东西，需要什么样的输入？

需要验证编码器本身，比如新写的帧间预测模块、码率控制策略、量化矩阵，那这份数据集的匹配度很高。原始无压缩、原生 120fps、8bit 与 10bit 双版本、内容维度标注齐全，这几个条件同时满足的公开资源并不多。特别是 120fps 这一项，在高帧率内容越来越多的当下，是很多老测试集的空白区。

需要验证的是整条链路，比如播放器在 4K 高帧率下的解码性能、显卡的硬解能力、传输过程中的卡顿表现，也能用，但要清楚你测的是链路不是编码器，结论别往编码效率上引。

但有几类场景，用它就是给自己找麻烦。第一类是机器学习训练。这 16 段素材没有标注、没有目标框、没有分割掩码，场景类型也集中在自然风光和人像，拿它训练检测或识别模型，泛化能力会很差。第二类是需要长镜头的分析，每段只有 5 秒或 12 秒，做时序行为分析、长视频理解根本不够。第三类是对内容多样性要求极高的主观评测，16 段素材撑不起大规模主观实验的样本量。第四类是商用产品素材，这份数据集的许可是非商业用途，商用前必须另行确认授权。

还有一笔账要提前算：存储。前面推算过，一段 600 帧的 8bit 4:2:0 4K 序列约 7GB，10bit 约 14GB，16 段双版本铺开是三百多 GB 的量级。加上编码后的码流、解码后的重建序列、中间缓存，实际占用轻松翻倍。用之前先看看硬盘余量，别跑到一半发现空间不够，那种感觉比算法不收敛还难受。

那次翻车之后，我给自己定了个习惯：不管拿到什么测试集，先画 SI-TI 散点图，确认覆盖范围对得上我要验证的问题，再动手跑第一个码率点。图不对，后面跑得再漂亮也是白跑。希望帮到你。

本文还有配套的精品资源，点击获取