1. 先搞清楚为什么360°视频的编码测试不能照搬平面视频的方案做视频编码的人都知道评测一个编码器性能最稳妥的方式就是搭建一套标准的测试条件跑几个典型序列对比码率和失真。这套方法论在传统2D视频上已经很成熟了HM、VTM、x265这些编码器的论文里到处都是基于CTCCommon Test Conditions的对比数据。但是一旦到了360°视频问题就没那么简单了。360°视频本质上是一个球面视频人眼看到的内容取决于当前视口viewport指向哪里。而编码器处理的却是平面像素也就是说你得先把球面映射到平面让编码器处理一个“看起来像普通视频”的矩形帧。这个映射过程会引入各种几何畸变不同投影格式下同一段球面内容对应到平面上的像素分布完全不同。我在实际测试里踩过一个大坑直接用普通HEVC编码器跑ERP格式的360°视频然后用全帧平均PSNR评价编码性能结果某款编码器跑出来的BD-Rate数据异常好看后来才发现是投影格式和失真度量方式不匹配导致的假象。那一次教训之后我彻底梳理了一遍360°视频编码性能评估的常见测试条件和参考配置今天把整套流程掰开揉碎讲清楚。这套方案适合谁如果你是做编码器研发、视频传输优化、直播平台画质调优的工程师或者在做360°视频编码方向的研究生这篇文章应该能让你少走不少弯路。我会从测试条件怎么搭、参考软件怎么配、评估指标怎么选、常见坑怎么避这四个维度逐一展开。2. 整个评测流程的设计思路球面内容平面编码加权比较2.1 评测体系的三个核心环节360°视频的编码评估拆开来看无非是三个环节输入准备、编码压缩、质量度量。但关键在于每个环节都比普通2D视频多了一层“球面到平面”的转换。输入准备阶段要解决的是“原始内容长什么样”。360°视频原始素材通常来自多个鱼眼镜头拼接拼接之后一般会输出成ERPEquirectangular Projection等距柱状投影格式——就是那种长宽比2:1的“世界地图”画面水平方向是360度垂直方向是180度。编码器不认识球面所以你得给它这种展开后的平面矩阵。编码压缩阶段本质上还是用传统混合编码框架做压缩但问题是ERP格式帧里每个像素代表的球面面积不一样。赤道附近的像素在球面上对应的面积大北极南极附近的像素对应的面积特别小也就是严重的过采样。如果直接套用普通编码器的码率分配策略编码器会把大量码率浪费在高纬度区域的冗余像素上而人眼真正关注的中低纬度内容反而得不到足够的码率支持。质量度量阶段这就是360°视频评估最容易出问题的地方。普通视频算PSNR每个像素一视同仁地参与计算。但360°视频如果也这么干高纬度那些大量冗余像素就会把PSNR数值“稀释”掉导致一个视觉上很差的编码结果反而PSNR很高。所以业界提出了各种球面加权的失真度量方法比如WS-PSNR、CPP-PSNR或者干脆按照人眼实际观看的视口去计算视口PSNR。2.2 为什么业界普遍不接受“裸算PSNR”我用一个生活化的例子解释一下这个问题。假设你有一张世界地图上面的内容分布很不均匀靠近北极和南极的区域几乎全是洋面或大片无意义的纹理。你想给这张地图做一个压缩压缩算法很“公平”把每一平方厘米的纸张都分配相同的压缩误差预算。结果就是新加坡、伦敦这些赤道和中纬度地区的细节已经被压成马赛克了但北极地区的浮冰还清清楚楚。你回头看整体PSNR数字还挺高因为浮冰区域的像素占了大头。这就是裸算PSNR在360°视频上的典型失效场景。从几何上看ERP投影这种格式在纬度方向的采样密度不均匀球面上等面积的一个环带映射到ERP帧里所占的行数随纬度升高而急剧增加。具体来说球面上任意一个像素对应的球面面积正比于纬度的余弦值而整个平面帧的像素面积是固定的。这就要求我们在计算失真时给每个像素乘以一个cos(latitude)的权重才算真正公平地反映了球面内容的失真程度。3. 搭建一套标准测试条件这步定了你后续所有结论的成立与否3.1 序列选择分辨率、时长、内容类型一个都不能少我做的第一件事是整理测试序列集。360°视频测试序列的选取行业内基本延续JVETJoint Video Experts Team相关测试文档里的做法一般会覆盖4K到8K的分辨率帧率30fps或60fps时长控制在10秒到20秒。常见的序列包括室内场景比如会议室、博物馆、室外场景航拍、街景、运动场景演唱会、体育赛事等。挑序列的核心原则是内容多样性——你的编码器不可能只在风景片上表现好还得在纹理复杂度高的场景下扛得住。我实测下来的经验是分辨率建议至少包含4K3840×1920和6K6144×3072两个档位如果是做极致性能验证再加一个8K7680×3840档位。低分辨率序列在评估高压缩比场景下的性能时参考价值有限因为360°视频的实际传输带宽普遍吃紧大多数应用场景跑的是4K以下但编码器性能评估需要覆盖足够的空间分辨率范围。帧率方面30fps用于常规评估如果有清晰度-帧率联合优化的研究需求需要60fps序列。时长为10秒是一个比较合适的选择太短了量化参数调节造成的帧间质量波动看不出来太长了编码时间和计算资源的开销成倍上升。3.2 关键参数配置QP点、编码结构、运动补偿精度测试条件的核心是量化参数QP的选择。行业里最常用的做法是选4个QP点22、27、32、37。这4个点覆盖了从高质量低压缩到低质量高压缩的典型范围。为什么从22开始而不是从17开始因为360°视频本身经过投影映射后引入了插值失真过低的QP点比如17以下会让编码器去“精雕细琢”那些本来就不准确的插值像素浪费码率而且对最终主观体验的提升微乎其微。编码结构决定参考帧的组织方式主流的配置有三种全帧内All-Intra每帧都是I帧编码复杂度高码率也最高通常只用于评估编码器最高质量的性能上限或者用作随机访问性能的对照组。随机访问Random Access周期性插入I帧比如每隔32帧一个IRAP内部用分层B帧结构。这是最接近实际点播和直播场景的配置也是我重点推荐的评测配置。低延迟Low-Delay只有第一帧是I帧后续全部用P帧或B帧用于实时通信场景。延迟低但压缩效率相对受限。我自己的习惯是如果是横向对比多个编码器优先用随机访问配置拉BD-Rate曲线因为它的压缩效率曲线最稳定受参考帧结构选择的影响最小。低延迟配置做补充验证。还有一个容易忽略的参数——运动估计精度。HEVC/VVC参考软件里运动估计的精度一般可以设置到四分之一像素。360°视频经过投影之后局部区域的几何变形非常剧烈尤其是在ERP格式的极地区域四分之一像素插值的可靠性会下降。不过我实测下来这种影响在整体BD-Rate上的表现不大不用太纠结保持参考配置默认即可。注意如果你使用不同编码器做对比它们的运动估计搜索范围、搜索算法、变换划分深度这些细节参数务必保持同一配置等级否则你对比出来的BD-Rate差距可能根本不是算法本身的差距而是参数配置的差距。3.3 投影格式要不要统一这是我踩过最深的坑测试条件里还牵涉一个关键决策统一使用ERP还是允许各编码器自由选择帧内投影格式。从纯粹的角度看把ERP作为基准格式是最稳妥的因为绝大多数公开测试序列都是ERP格式发布的如果换成CMP立方体投影或EAC等面积立方体投影你还需要额外做投影转换而投影转换本身就会引入插值误差这个误差会污染你的最终对比数据。但如果你做的是投影自适应编码方向比如按内容自适应切换投影格式那就得在统一比较基准的基础上额外测量投影格式切换带来的增益或损耗这时就要引入360Lib这样的投影格式转换工具来保证转换过程的公平性和一致性。我踩过的一个深坑是对比A厂商编码器和B厂商编码器时A厂商用了ERP输入B厂商在内部做了到EAC的转换。结果B厂商的数据整体比A厂商好我还以为是B厂商的编码算法先进。后来逐帧对比码率分布才发现EAC投影减少了极地区域的像素冗余码率自然就降下来了。这压根就是投影格式差异带来的不是编码器性能差异。从那以后我的所有对比实验一律强制使用同一投影格式输入。4. 软件参考配置从HM/NVTM到x265手把手教你搭环境4.1 参考软件怎么选360Lib 标准编码器还是直接上发行版做编码器性能评估业界最保守也最被认可的做法是使用标准的编码器参考软件搭配360Lib这类360°视频处理工具库。HEVCH.265的参考软件是HMVVCH.266的参考软件是VTM这两个是学术和标准界公认的基准。360Lib是JVET配套发布的360°视频工具库负责投影变换、视口渲染、球面失真度量等环节。具体到版本我建议用HM-16.20以上版本配合配套的360Lib版本。如果做VVC方向的评估VTM-10.0以上版本对360°视频的编码工具支持已经比较完整。参考软件的优势在于稳定、可信、被论文审稿人认可缺点是编码速度极慢——4K序列用HM跑All-Intra配置单帧编码耗时可能到秒级甚至几十秒级一整条10秒序列跑下来少则几小时多则一整天。如果追求效率或者做大规模参数扫参实验可以用x265/x264这类工业级编码器。x265支持HEVC标准的绝大多数工具压缩效率比HM略低但速度提升好几个数量级。做工程落地的评估我一般两边都跑参考软件出基准曲线x265出工程性能对比两者结合更有说服力。4.2 HM 360Lib的编译和配置要点编译这块我不展开讲具体命令了不同系统的编译步骤大家都能在官方文档里找到。我想重点说的是配置文件里的几个关键字段。首先360Lib的配置里必须指定输入投影格式和输出编码格式。常见做法是输入ERP不做转换直接编码配置如下InputBitDepth : 10 FrameRate : 30 SourceWidth : 3840 SourceHeight : 1920 InputFile : source_4k_10bit.yuv ReconFile : recon_4k_10bit.yuv FramesToBeEncoded : 300注意这里的SourceWidth和SourceHeight必须是ERP帧的实际像素尺寸而且宽高比必须是2:1这是ERP格式的硬性约束。如果宽高比不是2:1360Lib里的很多几何处理函数会直接报错或产出错误结果。然后是编码器侧配置。在encoder_randomaccess_main10.cfg这类标准配置的基础上需要修改QP和编码帧结构QP : 22 IntraPeriod : 32 DecodingRefreshType : 1 GOPSize : 16IntraPeriod设32表示每32帧一个I帧DecodingRefreshType选1表示使用CRAClean Random Access帧这是随机访问配置的标准做法。GOPSize设16表示一个GOP包含16帧分层B帧结构由GOP配置文件里的层级参数决定。注意如果你的测试序列是10比特位深360°视频原始素材现在基本都走10比特了配置文件里InputBitDepth和编码器内部位深参数必须一致否则会在像素值域上出现偏移导致编码重建帧的PSNR直接失真几个dB。这个问题我见过太多人踩了。4.3 用x265作为快速评估参考配置时的参数设置x265没有专门为360°视频做处理逻辑但因为它本身就是一个高效的HEVC编码器你可以直接用ERP格式输入做快速评估。我的参考配置如下x265 --input source_4k_10bit.yuv \ --input-res 3840x1920 \ --fps 30 \ --input-depth 10 \ --qp 27 \ --profile main10 \ --keyint 32 \ --min-keyint 32 \ --bframes 3 \ --no-open-gop \ --output output_4k_27.bin \ --y4m 2/dev/null这里面有几个参数对360°视频特别重要。--no-open-gop是为了保证GOP结构与HM测试条件里的封闭GOP一致开闭GOP在码率控制上会有微小差异对比时一定要对齐。--bframes 3对应的是4层B帧结构在RD率失真性能上比较接近标准配置。x265跑起来很快一分钟内就能完成几秒钟序列的编码适合快速验证想法。但务必要注意x265的码控算法和HM的拉格朗日优化策略不同两者之间的BD-Rate对比只能反映工程实现层面的差异不能完全等同于算法层面的优劣。做标准型结论时还是要回到参考软件的结果上。4.4 360Lib里投影转换和失真计算的用法360Lib最大的价值在于它提供了完整的投影转换和质量评估接口。如果你需要把ERP序列转成CMP或EAC格式再做测试或者需要把编码重建的平面帧映射回球面做评估360Lib的工具命令可以帮你实现。投影转换命令的大致格式如下ffmpeg -i source_erp.yuv -pix_fmt yuv420p10le -s 3840x1920 -f rawvideo - | \ 360LibConvert -o recon_cmp.yuv -w 3840 -h 1920 -f erp_to_cmp ...各个版本的具体参数名有差异实操时先查看-h帮助信息。还有一个需要注意的地方投影转换过程中的插值滤波器类型双线性、双三次、兰索斯等会影响转换后的内容质量。对比实验里所有序列的投影转换必须使用同样的插值滤波器否则转换误差的区别会被误判为编码器性能的区别。5. 评估指标从整体球面到人眼视口三级指标各有分工5.1 WS-PSNR最简单也最实用的球面加权PSNRWS-PSNR全称是Weighted to Spherically-uniform PSNR。它做的事情其实很直白在计算原始视频帧和重建视频帧的均方误差时对每个像素的误差乘以一个权重因子这个权重因子正比于该像素在球面上对应的面积权重。具体来说在ERP格式中第i行像素的权重是cos(latitude(i))其中latitude是该行对应球面的纬度。这个权重因子怎么理解我用一个比方球面上的每个点代表单位球面上固定的立体角但ERP帧里不同行的像素密度不同。纬度越高该行像素在球面上对应的立体角越小也就是说这一行像素对“球面整体质量”的贡献越小。加权平均之后高纬度区域的大量像素不再喧宾夺主PSNR数值更接近人眼对整体球面质量的平均感受。计算方式如下伪代码思路import numpy as np # y,u,v是重建帧和原始帧的像素值矩阵height和width是帧尺寸 weight np.cos(np.linspace(np.pi/2, -np.pi/2, height)) weight weight / weight.sum() mse np.average((recon - orig) ** 2, axis(0, 2), weightsweight) psnr 10 * np.log10((2**bitdepth - 1) ** 2 / mse)这段代码看着简单但有个容易出错的点权重矩阵的纬度方向是从上到下还是从下到上对结果没有影响因为cos函数关于赤道对称。但如果你用的是加了畸变补偿的EAC格式做输入权重就复杂了得参考360Lib里预先计算好的权重映射表不能直接用cos公式。顺便说一下WS-PSNR不需要把重建帧映射回球面直接在平面帧上算加权即可这是它高效的主要原因也是它不处理投影格式间差异问题的原因所在。5.2 CPP-PSNR直接回到球面上去算误差CPP-PSNRCraster Parabolic Projection PSNR的思路更彻底把待评估的重建ERP帧重新映射到一个等面积的投影平面上在这个CPP投影平面上每个像素对应的球面面积是相等的然后在这个平面上计算PSNR。等效于绕过“权重”这种软处理直接在物理均匀的采样域里做误差度量。从数学上讲CPP是一种等面积圆柱投影纬线按照抛物线关系进行非线性拉伸导致高纬度区域在CPP平面上的行数减少赤道附近的行数增加。误差计算时每个像素等权因为CPP平面本身就已经是等面积映射了。实际使用中CPP-PSNR和WS-PSNR的结果通常高度相关但CPP-PSNR需要额外的重采样过程会引入一点额外的计算开销而且重采样插值的选择会影响数值精度。我的习惯是如果核心结论依赖个别序列的数据我会同时算WS-PSNR和CPP-PSNR交叉验证如果只是批量筛选编码器参数用WS-PSNR就完全够了。5.3 视口级指标贴近真实观看体验的终极标尺WS-PSNR和CPP-PSNR衡量的都是“整个球面的平均质量”但人眼一次只能看到一个视口的画面。VR头显里人眼可感知的范围大约只有水平90到120度、垂直90度上下的区域其他区域都在视野之外。换句话说球面平均质量很高不代表用户实际看到的画面清晰因为用户当前注视的视口可能恰好是球面质量较差的区域。视口PSNRViewport PSNR的思路是把渲染路径拉进来根据指定的视角方向把原始球面内容和重建球面内容分别渲染成视口平面图像然后计算普通PSNR或SSIM。这个指标更贴近真实体验但代价是需要指定观看方向、视场角、渲染分辨率等主观参数评估结果会随这些参数变化。我在做直播场景的QoE评估时会额外设置一条“用户典型观看轨迹”通常是水平方向绕着全景内容缓慢旋转模拟观众自然的头部运动然后计算这条轨迹上各视口PSNR的平均值。这样得出来的结果和用户实际反馈的主观画质评分相关度比纯WS-PSNR高不少。5.4 三个指标怎么配合使用我的执行顺序实际评估中我不会只依赖单一指标。我的流程是先跑全套序列的WS-PSNR快速得到BD-Rate总体趋势然后对差异超过1dB或BD-Rate差异超过3%的重点序列补算CPP-PSNR确认数值的可靠性最后如果要做主观体验声称再补一个有代表性的视口轨迹分析。这套顺序既控制计算开销又能保障结论可靠性。6. 拿真实序列跑一遍完整评估从编码到出BD-Rate6.1 编码执行前的最后一次检查清单我每次正式跑实验前都会检查这几项全是踩过坑之后沉淀下来的输入YUV的位深和色彩空间是否与配置一致。360°视频测试序列最常见的是10比特4:2:0少数是12比特。编码器配置里的InternalBitDepth、InputBitDepth必须完全对应。输入序列的像素范围和文件大小是否符合预期。一个10比特4K ERP序列单帧大小是3840×1920×1.54:2:0采样×2字节10比特按2字节存储约等于22MB300帧就是6.6GB。如果你的文件大小和这差得离谱多半是位深或分辨率搞错了。编码后重建帧的PSNR基线是否在合理范围内。在QP22下4K序列的PSNR一般在40dB以上如果低于38dB你需要检查是不是码控问题或位深错位。这些都确认无误后才开始正式跑。6.2 完整命令配置与跑批流程以HM参考软件为例跑一个QP点的大致命令如下TAppEncoder -c cfg/encoder_randomaccess_main10.cfg \ -c cfg/360_erp_4k.cfg \ -f 300 \ -q 27 \ --InputFilesource_4k.yuv \ --ReconFilerecon_4k.qp27.yuv \ --BitstreamFileencode.qp27.bin跑完四个QP点之后你会得到两组关键数据每组QP下的输出码率可以从编码日志的比特统计里读出来和重建帧与原始帧的WS-PSNR。然后用脚本做4点拟合算BD-Rate这个业界常用工具格式也相对统一能保证你的数据和别人发的论文有可比性。6.3 测试过程中记录下来的几个典型数据形态为了让大家对“正常结果”有个感性认识我列一个典型的4K ERP测试结果趋势数字经过脱敏处理QP码率(Mbps)WS-PSNR(dB)2248.542.12728.339.43215.636.8378.934.2这个趋势算是正常QP每增加5码率大约下降40%到45%PSNR大约下降2到3dB。如果你的数据出现某个QP点码率异常高或PSNR异常低的情况大概率不是编码器的问题而是输入源或配置的问题。这时候按第6.1节的清单逐项排查通常能找到原因。7. 我把这些年踩过的坑整理成了一张速查表7.1 问题现象与根因对照异常现象常见根因解决办法WS-PSNR整体偏低比同等配置低3dB以上位深配置错误8比特内容按10比特配置核对输入位深使用ffprobe验证YUV文件属性某个QP点的码率突然跳变曲线不平滑输入序列前几帧包含淡入淡出或黑帧裁剪前几帧或者从第N帧开始统计BD-Rate对比结果与主观体验严重不一致只用了裸PSNR没有用WS-PSNR或视口指标换用加权指标重新评估两个编码器的对比结果在投影转换后失真投影转换的插值滤波器不一致统一插值滤波器类型和参数部分序列编码时间异常长ERP高分辨率带来的超高复杂度确认是否启用了WPP、SIMD优化考虑裁剪序列7.2 一个印象最深的排查案例去年做某个直播项目的编码器选型时我们在两个编码器之间对比A编码器在QP22和QP27下码率略高但PSNR也略高BD-Rate算下来基本持平。但用户那边主观反馈A编码器画面明显锐利B编码器画面发糊。我一开始以为是用裸PSNR导致的误判后来换成WS-PSNR之后发现两者的差值依然不大。最后逐帧去查编码树的划分情况才发现B编码器在ERP格式的高纬度区域倾向于用更大的编码单元做合并因为那些区域纹理简单编码器判定不需要精细划分。但用户在观看过程中旋转视角时会经过这些区域虽然停留时间短但明显感觉到画面“闪了一下”。这个问题靠整体指标根本测不出来只能靠视口级指标或者直接做主观测试。那次之后我在评估报告里增加了“视口内容一致性”分析在高纬度区域重点检查编码单元划分的一致性。7.3 提高评估效率的几个实践建议360°视频编码评估的计算开销比普通视频要大不少。我的经验是分三个层次管理成本第一个层次快速筛选用x265所有序列所有QP点跑一遍几个小时能出全部数据。这时候只看整体趋势不求精确结论。第二个层次选代表序列一般3到4个内容类型覆盖足够用HM或VTM跑全QP点用于对标论文数据或做精细算法对比。第三个层次针对重点方向或重大结论差异做视口轨迹分析和主观测试这一层最耗时但结论最硬。另外建议把所有测试序列统一存成10比特YUV格式避免每次评估前还要做格式转换。转换本身会引入不可逆的损失一旦原始素材被低精度转换污染以后所有实验数据都会带着这个误差溯源都困难。8. 最后分享一点我个人的使用体会做了这么久的360°视频编码评估我的整体感受是搭建一套测试环境本身不难但让评测结果既公平又有说服力需要花不少心思在那些“看不见的细节”上。投影格式是否统一、加权指标是否使用、参考配置是否对齐这些小决定会直接撼动你最终结论的可靠性。如果你刚开始接触这个方向我建议不要急着跑大规模对比先拿1个序列、2个QP点、1种指标把整条流程完整走通确认每一步输出都合理再扩展开。这比一次跑完所有数据然后发现某一步错了全部推翻重来要高效得多。另外我也在尝试把一些AI生成的动态全景序列比如用扩散模型合成的镜头旋转视频纳入测试集这类内容的时间一致性和传统拼接片段差异很大对编码器的运动估计和参考帧管理提出了新的挑战后续有机会再单独写一篇聊聊。