简介：UVG 4K视频数据集是面向视频编码研究、编解码器开发与画质评测人员的专业测试资源，聚焦高帧率超高清序列在HEVC/H.265与VVC/H.266参考编解码器下的率失真性能与编码复杂度分析。数据集包含16个4K（3840×2160）自然序列，帧率为50或120 fps，提供8位与10位4:2:0 YUV原始格式，由Sony F65拍摄，采用非商业CC BY-NC许可，适合下一代VVC编解码器的主观与客观质量评估。资源包为1个PDF文件，约931KB，内容系统梳理了各序列的空间与时间感知信息、率失真行为及编码复杂度对比，并说明其与现有4K测试集的互补关系。目前已有137人学习，适合视频编码方向的研究生、算法工程师及标准评测人员快速掌握数据集构成与评测结论，为编解码实验选型与性能分析提供参考。
1. 拿到 UVG 4K 数据集之后，先想清楚你要验证什么
很多做视频编码的同行第一次接触 UVG 4K 视频数据集，都是被它那几个数字吸引：3840×2160、50fps 和 120fps 两套帧率、覆盖多种运动复杂度。但真正把它用起来的人会发现，这套素材的价值不在"清晰"，而在"可控"——它把编码器在不同运动强度、不同纹理密度下的表现差异，压缩进了十几个可复现的片段里。你要做的不是拿它当播放素材，而是拿它当一把尺子，去量自己的编码器、码率控制算法或者质量评估模型到底在哪个环节掉链子。
这篇文章面向三类人：正在做 HEVC/VVC/AV1 编码器调优的工程师、需要给码率控制或感知质量模型准备测试集的算法同学、以及要给实时传输链路做压力测试的开发者。我会从数据集的结构讲起，一路落到怎么切片段、怎么跑编码、怎么读结果，中间穿插我自己踩过的坑。50fps 和 120fps 这两个帧率不是随便标的，它们对应的是两类完全不同的应用场景，后面会展开说。
2. UVG 4K 数据集的构成与选型逻辑：为什么是这 16 段而不是别的
2.1 分辨率、帧率与色度采样背后的取舍
UVG 4K 的每段素材都是 3840×2160 的 YUV420 格式，位深有 8bit 和 10bit 两个版本。YUV420 意味着色度平面在水平和垂直方向都做了 2:1 下采样，这对编码器来说是个友好的起点——大多数消费级编码管线本来就在这个格式上工作。但要注意，10bit 版本不是简单地把 8bit 左移两位，它的色深信息是独立采集的，做 HDR 相关实验时别拿 8bit 版本凑合。
帧率方面，50fps 的片段更接近广播和流媒体场景，120fps 则偏向高帧率采集、慢动作回放和 VR 渲染。这里有个容易被忽略的点：120fps 素材在时域上的冗余度比 50fps 高得多，如果你用同一套 GOP 结构和码率控制参数去跑，120fps 的片段往往会给出偏乐观的 RD 曲线。我一般会针对帧率分别调 GOP 长度，50fps 用 32 或 48，120fps 用 64 甚至 96，让时域预测有足够的参考帧可用。
色度采样和位深这两个参数在配置文件里是写死的，但你在做预处理时要注意：如果下游编码器只支持 8bit 输入，而你想用 10bit 素材做质量基准，得先做位深转换，转换公式别用简单的截断，用带抖动的量化，否则暗部会出现 banding，后面算 PSNR 的时候会莫名其妙低一截。
2.2 运动复杂度分级：从静态纹理到高速运动
这 16 段素材大致可以分成四档：静态纹理为主、中低速运动、高速运动、以及混合场景。静态纹理那几段适合测帧内编码效率和纹理保持能力，高速运动那几段则是测时域预测和运动估计的试金石。我习惯在跑完整测试前，先挑三段做快速筛查：一段静态、一段中速、一段高速，用固定 QP 跑一遍，看编码器的码率波动是否在预期范围内。
选型的时候别只看分辨率。有些片段虽然也是 4K，但画面内容以平坦区域为主，编码器随便跑跑码率就很低，这种素材用来做码率控制算法的压力测试意义不大。真正能暴露问题的是那些纹理密集且运动剧烈的片段，它们会让码率控制器的缓冲区频繁触顶或触底。
2.3 与同类数据集的差异：为什么不用自己拍
自己拍 4K 素材不是不行，但成本高且不可复现。UVG 的价值在于它的采集条件、后期处理流程是固定的，你这次跑出来的结果，换台机器、换个时间再跑，只要编码器版本一致，结果应该能对上。这对做算法对比和论文复现至关重要。另外，它的片段长度适中，每段几秒钟到十几秒钟，既不会短到统计不显著，也不会长到单次编码跑几个小时。
如果你手头有别的 4K 数据集，可以混用，但要注意色彩空间和位深的统一。我见过有人把不同来源的 YUV 直接拼在一起跑，结果 RD 曲线出现莫名其妙的拐点，查了半天发现是其中一段的 UV 平面顺序反了。
3. 从下载到跑通第一组编码：最小可复现流程
3.1 目录结构与文件命名规律
下载下来的数据集通常按片段名分目录，每个目录下有 YUV 文件和可能的配置文件。文件命名一般包含分辨率、帧率和位深信息，比如类似片段名_3840x2160_50fps_8bit.yuv这种格式。别急着批量处理，先拿一段确认帧数：用文件大小除以单帧字节数，单帧字节数 = 3840×2160×1.5（YUV420 的系数），8bit 时再乘以 1，10bit 时乘以 2。
# 计算 YUV420 8bit 单帧大小并推算总帧数 width=3840 height=2160 bytes_per_frame=$((width * height * 3 / 2)) file_size=$(stat -c%s "sample_3840x2160_50fps_8bit.yuv") total_frames=$((file_size / bytes_per_frame)) echo "单帧字节: $bytes_per_frame, 总帧数: $total_frames"这段脚本的逻辑很直接：YUV420 的 Y 平面占 width×height，U 和 V 各占四分之一，合计 1.5 倍。算出来的帧数要和你预期的时长对得上，如果差得离谱，可能是文件不完整或者位深判断错了。
3.2 用 FFmpeg 做格式转换与片段截取
原始 YUV 文件体积大，直接喂给编码器没问题，但做快速实验时截取前 N 帧能省不少时间。FFmpeg 处理 rawvideo 需要显式指定像素格式和分辨率。
# 截取前 100 帧并转成 y4m 格式，方便后续工具读取 ffmpeg -f rawvideo -pix_fmt yuv420p -s 3840x2160 -r 50 \ -i sample_3840x2160_50fps_8bit.yuv \ -frames:v 100 -f yuv4mpegpipe sample_100f.y4m参数说明：-pix_fmt yuv420p对应 8bit，如果是 10bit 要改成yuv420p10le；-r 50是输入帧率，必须和素材实际帧率一致，否则时间戳会乱；-frames:v 100限制输出帧数。转成 y4m 的好处是头部带了元信息，后面用 x264、x265 或者 VTM 都能直接读，不用再重复指定分辨率。
3.3 用 x265 跑第一组固定 QP 编码
选 x265 是因为它参数透明、社区资料多，适合做基线。下面这组命令跑 4 个 QP 点，输出 CSV 格式的统计信息。
for qp in 22 27 32 37; do x265 --input sample_100f.y4m --fps 50 --input-res 3840x2160 \ --qp $qp --keyint 48 --min-keyint 48 --scenecut 0 \ --csv "result_qp${qp}.csv" --csv-log-level 2 \ -o "out_qp${qp}.hevc" 2> "log_qp${qp}.txt" done关键参数：--keyint 48和--min-keyint 48固定 GOP 长度，避免场景切换干扰 RD 对比；--scenecut 0关闭场景切换检测，保证每个 QP 点的 GOP 结构一致；--csv-log-level 2输出帧级统计，后面画 RD 曲线要用。跑完之后看 log 里的码率和 PSNR，如果某个 QP 点的码率异常高，先检查是不是素材里有强噪声或者编码器开了什么默认滤镜。
3.4 从 CSV 提取码率与 PSNR 画 RD 曲线
x265 的 CSV 里字段很多，我们只需要几列：帧序号、QP、码率、Y-PSNR、U-PSNR、V-PSNR。用 Python 做聚合和绘图。
import pandas as pd import matplotlib.pyplot as plt results = [] for qp in [22, 27, 32, 37]: df = pd.read_csv(f"result_qp{qp}.csv") # 跳过表头行，按实际列名取 avg_bitrate = df["Bitrate"].mean() avg_psnr = df["Y-PSNR"].mean() results.append({"qp": qp, "bitrate": avg_bitrate, "psnr": avg_psnr}) rd = pd.DataFrame(results).sort_values("bitrate") plt.plot(rd["bitrate"], rd["psnr"], marker="o") plt.xlabel("Bitrate (kbps)") plt.ylabel("Y-PSNR (dB)") plt.title("RD Curve - UVG 4K 50fps Sample") plt.grid(True) plt.savefig("rd_curve.png", dpi=150)这段代码的逻辑是：每个 QP 点取所有帧的平均码率和平均 PSNR，然后按码率排序画线。注意 PSNR 要取 Y 分量，因为人眼对亮度更敏感，U/V 的 PSNR 一般只做参考。如果曲线出现交叉或者斜率异常，多半是某个 QP 点的编码参数没对齐，回去检查 keyint 和 scenecut 是否一致。
4. 50fps 与 120fps 的编码参数差异：别用一套配置打天下
4.1 帧率对时域预测的影响
50fps 相邻帧之间的时间间隔是 20ms，120fps 是 8.3ms。间隔越小，运动物体的位移越小，运动估计的搜索范围可以相应缩小，但参考帧的数量可以增加。我在跑 120fps 素材时，会把--bframes从 4 提到 6 甚至 8，因为 B 帧的双向预测在高帧率下收益更明显。同时--ref从 4 提到 6，让每个 P 帧有更多参考选择。
但这不是无脑加。参考帧多了，编码器的内存占用和计算量都会上去。如果你的机器内存紧张，或者要做实时编码，得在收益和开销之间找平衡点。我一般会跑一组对比实验：固定 QP，只改 ref 和 bframes，看 BD-Rate 能改善多少，如果改善小于 2%，就不值得加。
4.2 GOP 结构与场景切换的配合
50fps 素材里如果有快速场景切换，固定 GOP 会导致切换点附近的帧质量骤降。这时候可以开--scenecut，让编码器在检测到场景切换时插入 I 帧。但开了 scenecut 之后，不同 QP 点的 GOP 结构就不一致了，RD 对比的公平性会打折扣。我的做法是：做算法对比时关掉 scenecut，保证结构一致；做实际部署评估时打开，看真实场景下的表现。
120fps 素材的场景切换通常更平滑，因为帧率高，切换过程被拆散到更多帧里。这时候固定 GOP 的副作用没那么大，可以放心用长 GOP。
4.3 码率控制模式的选择：CQP、ABR 还是 CRF
做 RD 曲线用 CQP（固定 QP），因为你要的是不同质量点下的码率表现。做实际传输评估用 ABR（平均码率），看码率波动和缓冲区行为。CRF 介于两者之间，适合做质量一致性要求高的场景。
我见过有人用 ABR 跑 RD 曲线，结果曲线抖得没法看，因为 ABR 的码率控制本身就在动态调整 QP，你没法把码率和质量对应起来。记住一个原则：要对比编码效率，用 CQP；要模拟真实链路，用 ABR 或 CRF。
4.4 10bit 素材的编码注意事项
10bit 素材在 x265 里需要编译时开启高位深支持，运行时用--input-depth 10指定。如果编码器不支持 10bit，可以先转 8bit，但转换时的抖动量化要做好，否则暗部细节丢失会影响 PSNR 计算。另外，10bit 的 PSNR 计算方式和 8bit 略有不同，峰值从 255 变成 1023，算的时候别用错公式。
5. 避坑与排查：那些让我重跑一整天的细节
5.1 帧数对不上：文件截断还是位深判断错
现象：算出来的总帧数和预期时长差了几十帧。原因通常是文件下载不完整，或者位深判断错了——10bit 文件被当成 8bit 算，帧数会少一半。解决：先用ffprobe读文件头，确认 pix_fmt 和分辨率，再算帧数。如果文件确实不完整，重新下载对应片段。
5.2 PSNR 异常低：色彩空间或 UV 顺序反了
现象：某段素材的 PSNR 比其他段低 3dB 以上，但肉眼看不出明显差异。原因可能是 UV 平面顺序反了，或者色彩空间标记错误。解决：用ffmpeg转成 PNG 抽几帧看，确认颜色正常。如果颜色偏了，检查 YUV 文件的 UV 顺序是 U 在前还是 V 在前，必要时用-vf shuffleplanes交换。
5.3 编码速度突然变慢：参考帧或搜索范围开太大
现象：同样的机器，跑某段素材时速度只有其他段的一半。原因通常是该段运动剧烈，编码器自动增大了搜索范围，或者参考帧命中率低导致重复搜索。解决：先看 log 里的平均搜索点数，如果远高于其他段，可以适当限制--merange，或者降低--ref。但要注意，限制搜索范围可能会损失编码效率，得做权衡。
5.4 RD 曲线交叉：GOP 结构或 QP 步长不一致
现象：两个编码器的 RD 曲线在某个码率点交叉，看起来像是各有优劣。原因往往是 GOP 结构不同，或者 QP 步长不一致导致采样点没对齐。解决：固定 keyint、min-keyint、scenecut，用相同的 QP 列表跑，交叉点如果还在，再检查是不是某个编码器开了自适应量化之类的默认选项。
5.5 内存溢出：10bit 4K 素材的缓冲区计算
现象：跑 10bit 4K 素材时编码器崩溃，报内存分配失败。原因：10bit 每像素占 2 字节，4K 单帧的 YUV420 数据量是 8bit 的两倍，加上参考帧缓冲，内存需求翻倍不止。解决：减少同时打开的参考帧数量，或者分批处理，别一次性把整个片段读进内存。
6. 进阶用法：用 UVG 4K 做码率控制算法的压力测试
前面讲的都是基线流程，如果你要做码率控制算法的验证，UVG 4K 能提供比普通数据集更严苛的条件。我一般会构造一个"码率台阶"测试：让目标码率在短时间内大幅跳变，看控制器的收敛速度和超调量。
具体做法是：把一段 120fps 素材切成 10 秒的片段，前 3 秒目标码率设为 20Mbps，中间 4 秒跳到 5Mbps，最后 3 秒回到 20Mbps。用 ABR 模式跑，记录每帧的实际码率和缓冲区占用。
# 构造码率台阶：用 x265 的 zone 功能分段设置码率 x265 --input sample_120fps.y4m --fps 120 --input-res 3840x2160 \ --bitrate 20000 --vbv-maxrate 25000 --vbv-bufsize 30000 \ --zones 360,840,br=5000 --zones 840,1200,br=20000 \ --csv step_result.csv -o step_out.hevc 2> step_log.txt这里的--zones参数按帧号划分区间，360 帧对应 3 秒（120fps），840 帧对应 7 秒，1200 帧对应 10 秒。br=5000表示该区间目标码率 5Mbps。跑完之后看 CSV 里的实际码率曲线，如果下降沿有大幅超调，说明控制器的积分项太激进；如果上升沿收敛慢，说明比例项不够。
另一个进阶用法是做感知质量评估。UVG 4K 的素材纹理丰富，适合测 VMAF、SSIM 等指标在不同编码器下的表现差异。我习惯把 VMAF 和 PSNR 一起看：如果 VMAF 高但 PSNR 低，说明编码器在感知上做了优化，比如保留了更多纹理细节；反过来则可能是过度平滑了。
最后说一个我自己的习惯：每次跑完一组实验，先把原始 CSV 和配置文件打包存档，文件名带上日期和编码器版本。因为过几个月你回头看某个 RD 曲线，很可能想不起来当时用的什么参数。这个习惯帮我省过好几次重跑的功夫。希望帮到你。
本文还有配套的精品资源，点击获取
