1. 概念对齐HDR 与 SDR 的差别不在“亮”在“范围”HDR 视频与 SDR 视频这两个词几乎每个折腾过片源、播放器、电视设置的人都见过但真正能说清楚差别的人并不多。我见过太多人把 HDR 简单理解成“更亮”“更鲜艳”也见过有人把 SDR 片源塞进 HDR 容器里当 HDR 卖画面糊成一片还觉得是解码器不行。这篇东西想解决的就是这件事把 HDR 视频和 SDR 视频从标准、编码、元数据到播放链路的每一段拆开讲清楚让你拿到一个文件时能判断它到底是什么、该怎么处理、出了问题往哪儿查。内容适合三类人一类是刚开始接触蓝光原盘、压制、转码的爱好者想搞清楚那些“color_transfersmpte2084”“10bit 4:2:0”“MaxCLL”到底是什么一类是做视频内容、需要交付不同版本的技术人员甲方要 HDR 版本又要 SDR 版本你得知道两边不是简单调个亮度就行还有一类是折腾家庭影院的玩家设备都买了画面就是不对劲想找到是链路上哪一环掉了链子。三类人关注的点不一样但底层是同一套东西。1.1 三个维度亮度范围、色域范围、量化精度把 HDR 拆开其实是三个互相独立的维度同时在扩很多人只记住了第一个。亮度范围指画面能表达的明暗跨度SDR 的参考白通常按 100 nit 设计上限也就这么高HDR 的内容母版动辄按 1000 nit、4000 nit 做理论编码上限到 10000 nit。色域范围指能表达的颜色边界SDR 长期用 BT.709HDR 用 BT.2020后者在 CIE 1931 色度图上的覆盖面积大概是前者的两倍多。量化精度指用多少个数字台阶去描述一段连续的亮度或颜色SDR 常见 8bitHDR 基本要求 10bit 起步。这三个维度必须一起扩只扩一个就会出问题。只提亮度的结果就是高光全糊成白块因为 8bit 的码值台阶根本撑不住这么大的动态范围暗部一根一根的色带就是这么来的。只扩色域的后果更微妙在 BT.709 显示器上看 BT.2020 的内容如果不做正确的色彩转换颜色会偏得离谱红色发橙、绿色发灰。所以后面讲编码参数时你会看到色域标签color_primaries、传递函数color_transfer、矩阵系数color_space永远是一组出现缺一个都会让播放端猜错。我个人的经验是判断一个文件是不是“真 HDR”先别看它标称多少 nit先看它的三个标签是不是自洽。标签写着 bt2020 / smpte2084 / bt2020nc但内容是 8bit、码率只有 3 Mbps那大概率是拿 SDR 拉伸出来的。反过来一个 HLG 的 10bit 文件码率也不高但标签齐全、内容真实它在支持 HLG 的电视上观感会很自然。这就是“范围”和“标签”的区别范围是内容本身的物理属性标签是告诉播放端该怎么解释这些数字的说明书。1.2 为什么“能显示更亮”不等于“看得更清楚”这里有个特别容易被忽略的常识HDR 的价值主要不在亮的地方而在亮和暗同时存在的时候。举个数一个逆光的窗户场景SDR 版里窗外是一片纯白码值 235 顶死窗内的人脸为了看得见被提亮结果整张脸发灰、没有立体感。HDR 版里窗外可以是 800 nit、窗内人脸是 5 nit两者差了一百多倍但都在编码范围内人脸保留了层次窗外还留着云的纹理。换句话说HDR 扩的是动态范围的跨度不是把整幅画面往上推。这解释了一个反直觉的现象很多人第一次看 HDR 会觉得“怎么还没 SDR 亮”因为播放端做了正确的色调映射把整体亮度压在了显示器能力范围内只是高光和暗部的相对关系更接近真实。真正该看的指标是“同一帧里最亮和最暗能差多少档”不是绝对亮度值。这也带出一个实操上的坑调色或者转码时如果为了让画面“看起来更 HDR”而猛提整体亮度结果是中间调被推爆肤色发白画面失去层次。正确的做法是先确定参考白的位置再让高光自然往上延伸。后面第 5 节讲色调映射参数时会具体说这个“参考白”怎么在滤镜链里体现。1.3 一条链路里的分岔点从采集到显示一条完整的视频链路是采集 → 后期调色 → 编码 → 封装 → 传输 → 解码 → 显示。HDR 和 SDR 在这七段里几乎每一段都有分岔。采集端可能用不同的 Log 曲线后期的工作色彩空间可能是 Rec.2020 或者更大的线性空间编码时传递函数选 PQ 还是 HLG封装时要不要写元数据传输时带宽不够要不要降码率降位深解码端是硬解还是软解显示端的能力上限是多少、由谁来做 tone mapping。最要命的是最后一步tone mapping 到底由谁做。理想情况下内容带着元数据显示设备知道自己的能力自己决定怎么把 4000 nit 的内容压到 800 nit 的面板上。现实里可能播放器先压一遍系统再压一遍显示器又压一遍三次映射叠加画面必然发灰发闷。我见过不少人抱怨“HDR 片子看着像蒙了层雾”最后查出来是播放器和系统双重映射把播放器那一层关掉就正常了。这个排查思路在第 6、7 节会展开。所以下面我不会按“标准文档”的顺序讲而是按你实际会遇到的顺序先搞懂传递函数和色域这些决定数据含义的东西再看位深和采样这些决定数据精度的东西然后看元数据这个决定播放端行为的东西最后落到实操和排查。你可以按顺序读也可以直接跳到自己在意的章节。2. 传递函数与色域HDR 真正的技术骨架如果把 HDR 比作一套语言色域是它的词汇量传递函数是它的语法。词汇量决定你能说出多少种颜色语法决定这些词怎么排列、怎么被理解。很多人只盯着“10bit”“HDR”这些标签忽略了传递函数才是决定“这个数字代表多少亮度”的根本规则。同一个码值在不同传递函数下代表的物理亮度能差几十倍这才是为什么色彩标签错了一切都错。2.1 Gamma 曲线不是随便定的SDR 时代用的是 Gamma 曲线常见 BT.1886 定义的 Gamma 2.4也有用 2.2 的。它的作用是把人眼的非线性感知和显示设备的线性输出对齐人眼对暗部变化敏感、对高光变化迟钝所以编码时把更多码值分配给暗部显示时再用反向曲线还原。这是一套在 100 nit 上限内工作得很好的方案代价是它只能在有限范围内保持精度。Gamma 的本质是相对的码值 1.0 对应“最亮”至于这个“最亮”是 100 nit 还是 300 nit取决于显示设备。这带来一个好处同一份内容在不同亮度的屏幕上都能看也带来一个坏处没法精确表达“这个像素应该是 800 nit 而不是 200 nit”。HDR 要的恰恰是后者因为 HDR 的整个价值建立在“高光和中间调的绝对关系”上如果最亮值浮动那这个关系就散了。所以 HDR 换了两套思路PQ 走绝对亮度HLG 走相对但兼容。这两套不是谁更高级的问题是适用场景不同。下面分别说。2.2 PQ用绝对亮度说话的编码方式PQ 全称 Perceptual Quantizer定义在 SMPTE ST 2084 里后来被 ITU-R BT.2100 采纳。它的核心是把 0 到 10000 nit 的绝对亮度用一种符合人眼感知的曲线映射到 0 到 1 的归一化码值上。注意关键词是绝对码值 0.7514 在 PQ 下永远代表 1000 nit不管你的显示器是 300 nit 还是 1000 nit 面板这个对应关系不变。显示器显示不了的部分由 tone mapping 去压缩而不是靠改曲线。这条曲线的形状可以用公式算出来逆变换从亮度求码值大概是N ((c1 c2 * Y^m1) / (1 c3 * Y^m1)) ^ m2其中 Y 是归一化亮度实际亮度除以 10000m1 2610/16384 ≈ 0.1593m2 2523/4096 × 128 ≈ 78.84375c1 3424/4096 ≈ 0.8359c2 2413/4096 × 32 ≈ 18.8516c3 2392/4096 × 32 ≈ 18.6875。这些常数看着吓人实际用的时候你不需要手算但知道它们存在有好处因为你在调参数时会看到“PQ 编码下 100 nit 大概是多少码值”这类问题。我算过两组常用值可以直接记100 nit 在 PQ 下归一化约 0.512110bit 码值约 5241000 nit 归一化约 0.751410bit 码值约 769。这两个数字非常有用。第一它说明 SDR 的整个亮度范围只占 PQ 编码空间的中间一小段上面一大截码值是留给高光的所以 HDR 内容降位深到 8bit 时高光部分的台阶会特别明显。第二它说明把 SDR 内容“放进”PQ 容器时如果不做亮度重映射画面会整体发暗——因为原来码值 235 的白色现在只代表 100 nit而显示端可能按 200 nit 去解释它。注意PQ 是绝对亮度编码任何“把 SDR 直接标成 PQ”的操作本质上都是在撒谎播放端按 PQ 解释出来的画面一定是错的。正确的做法是用 zscale 之类的滤镜做真正的传递函数转换加色调映射。2.3 HLG带 SDR 兼容基因的方案HLG 全称 Hybrid Log-Gamma同样在 BT.2100 里定义。它的设计目标很明确让同一份信号在 SDR 电视上能看虽然效果打折在 HDR 电视上能发挥。做法是在曲线的低段用接近 Gamma 的形状高段逐渐过渡到对数形状整体是相对的没有规定绝对亮度参考由显示端按自己的峰值亮度去解释。这个特性让 HLG 在广播场景里特别吃香因为广播链路里你没法保证每个观众的设备能力兼容性是第一位的。代价是 HLG 的“HDR 感”通常没有 PQ 那么强烈因为它的高光延伸是相对的显示端亮度不同观感差异会比较大。我个人的观感是HLG 更适合纪录片、体育、自然类内容画面自然PQ 更适合电影因为电影母版本身就是在受控环境里按绝对亮度做的。实操里有个细节HLG 内容如果不带任何元数据播放端默认按 BT.2100 的参考条件解释问题不大但如果一个文件标着 HLG 而实际内容是 PQ 转换过来的画面会整体偏暗偏灰因为两套曲线的中段形状不同。判断方法还是看标签加实际抽帧亮度统计第 5 节会给具体命令。2.4 BT.709 与 BT.2020 的实际差距色域这块数字比想象中悬殊。BT.709 在 CIE 1931 xy 色度图上覆盖的面积大约是 0.1124 平方单位占整个可见色域的百分之三十多BT.2020 覆盖约 0.2358占比接近百分之七十六。也就是说理论上 BT.2020 的词汇量是 BT.709 的两倍出头。但这里必须泼一盆冷水目前绝大多数消费级显示设备都覆盖不了完整的 BT.2020。常见的量子点面板大概能到 BT.2020 的七成左右普通液晶更少。这意味着你看到的大多数“BT.2020 内容”实际显示时都被显示器按自己的能力裁剪过了。这不是骗局是物理限制标准先定得宽一点让内容有足够的余量设备慢慢追。对实操的影响是做 HDR 内容时色域标签必须写对但不要指望观众看到完整效果做 SDR 版本时从 BT.2020 往 BT.709 转换不能简单裁剪超出 BT.709 边界的颜色要做压缩映射否则会直接切平出现色块。常见的做法是用感知型色域映射算法把超出部分按比例往内收保持色相不变牺牲一点饱和度。这个步骤在调色软件里通常叫“色域映射”或者“gamut mapping”在命令行工具里也能做第 5 节会给例子。还有一点容易忽略白点。BT.709 和 BT.2020 都用 D65色度坐标是 (0.3127, 0.3290)所以在白点上两者是一致的。但如果你在转换过程中不小心把白点改了整幅画面会偏冷或偏暖而且这种偏移在所有色相上表现不一致非常难查。我踩过一次把一段素材从 BT.2020 转到 BT.709 时用了错误的矩阵肤色全变成蜡黄查了两天才发现是白点没保持。3. 位深、色度采样与量化容易被忽略的细节前面说的是“数据代表什么”这一节说“数据有多精细”。这两件事经常被混为一谈结果是有人以为把 8bit 转成 10bit 就变 HDR 了。位深和采样决定的是精度和台阶不改变数据的含义格式转换如果只改位深不改标签和曲线画质不会变好文件倒是会变大一圈。3.1 8bit 与 10bit 的真实差距8bit 每通道 256 个台阶10bit 是 1024 个看着只是四倍实际观感差距在暗部被放大。原因在于人眼对暗部的亮度变化特别敏感而 Gamma 或者 PQ 曲线都把大量码值分配给了暗部8bit 分到暗部的台阶依然不够用于是就出现色带banding。天空渐变、烟雾、暗场墙面这三个场景是色带的重灾区。HDR 基本强制 10bit 起步原因不只是暗部还有高光。前面算过PQ 编码下 100 nit 到 1000 nit 只占归一化码值 0.51 到 0.75 这一段10bit 下对应 524 到 769也就是 245 个台阶要描述十倍亮度变化。如果降到 8bit同样的区间只有 61 个台阶高光过渡必然出现一圈一圈的断层。这就是为什么 HDR 内容用 8bit 编码基本没有意义哪怕码率给到很高也救不回来。有人会问 12bit 是不是更好。理论上是的杜比影院级别的母版会用 12bit量化误差更小。但消费级分发基本停在 10bit因为 12bit 的码率代价换来的观感提升在家庭环境里很难察觉而且硬件解码支持也不普遍。我的建议是分发用 10bit母版和中间素材用 12bit 或更高别在分发环节追求 12bit。顺带说一个常见误解把 8bit 素材“转”成 10bit能不能消除色带答案是基本不能。已有的色带是量化误差转位深只是把误差原样搬到更大的台阶上不会凭空长出细节。要真正消除需要的是抖动dither或者去色带滤镜那是在做视觉补偿不是恢复信息。这点在做老片修复时特别重要别指望改个位深参数就完事。3.2 4:2:0 到底丢了什么色度采样 4:2:0 的意思是亮度Y全采样两个色度分量Cb、Cr在水平和垂直方向都减半。1080p 的 4:2:0 素材Y 是 1920×1080Cb 和 Cr 各是 960×540。人眼对色度的分辨率本来就低于亮度所以这个取舍在大部分画面里看不出来。但在两类画面上会露馅高饱和度的细线条和红蓝色的锐利边缘。前者比如彩色的细字、舞台灯光下的细密纹理后者比如红色衣服的边缘、蓝色背景前的头发丝。这些位置会出现色度溢出或者边缘发虚专业叫法是 chroma bleeding。HDR 内容的色域更宽、饱和度更高4:2:0 的损失会比 SDR 时代更明显所以有些高端分发会用 4:2:2代价是码率上去一截。实际工作里我的选择是分发用 4:2:0 10bit这是兼容性和体积的平衡点中间素材和调色输出用 4:2:2 或 4:4:4避免多次转码累积损失。千万别在 4:2:0 的素材上反复做转码每次转码都是一次色度重采样五六次之后画面会明显发糊尤其是红色区域。这个坑我在早期压制的时候踩得很惨一堆素材来回导最后成片颜色糊成一片只能重做。3.3 色域标签比数据本身更重要这一条是整篇文章里我最想强调的标签错了数据再准也没用。视频流里有三个关键标签分别告诉播放端“这些数字是什么颜色”“这些数字对应什么亮度曲线”“这些数字怎么从 YCbCr 还原成 RGB”。标签字段常见取值作用标错的后果color_primariesbt709 / bt2020定义 RGB 三原色的色度坐标颜色整体偏移红色发橙或发紫color_transferbt709 / smpte2084 / arib-std-b67定义码值到亮度的映射曲线画面整体过暗、过亮或发灰color_space矩阵bt709 / bt2020nc定义 YCbCr 与 RGB 的换算矩阵颜色饱和度异常肤色失真color_rangetv / pc定义 16-235 还是 0-255黑位发灰或暗部死黑我遇到过最典型的一次一段 BT.2020 的素材封装时矩阵标成了 bt709播放出来颜色浓得像加了滤镜绿色植物直接变成荧光绿。原因很简单BT.2020 的矩阵系数和 BT.709 不一样用错误的系数还原色度分量被放大了。改标签一秒钟解决。所以养成习惯任何转码、封装、剪辑输出之后都用工具把标签读一遍确认三个字段自洽。具体命令在第 5 节。这一步花十秒钟能省掉几小时的排查。4. 元数据与主流 HDR 路线元数据是 HDR 里最有“人为设计”味道的部分。它不参与画面数据的编码而是额外告诉播放端这份内容是按什么条件做的母版最亮能到多少平均亮度大概多少。播放端拿到这些信息才能决定怎么把内容映射到自己的屏幕上。没有元数据播放端只能猜猜错就出问题。4.1 静态元数据都在描述什么静态元数据顾名思义整部片子共用一套不随场景变化。最核心的三组信息是母版显示信息定义在 SMPTE ST 2086描述调色时用的监视器三原色的色度坐标、白点坐标、最大亮度和最小亮度。常见写法是G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)前面是色度坐标乘 50000 取整L 后面是最大亮度和最小亮度乘 10000 取整所以L(10000000,1)表示最大 1000 nit、最小 0.0001 nit。内容光级CTA-861.3 定义的 MaxCLL 和 MaxFALL。MaxCLL 是整部片子里单个像素出现过的最高亮度MaxFALL 是所有帧平均亮度的最大值。前者告诉播放端“最坏情况要多亮”后者告诉它“整体大概多亮”。这两个值如果标得离谱播放端的 tone mapping 就会判断失误。我见过标着 MaxCLL 4000 但实际内容最高只有 600 的片子播放端按 4000 去压缩结果整部片子被压得灰蒙蒙。HDR10 就是这套组合的代表BT.2020 色域 PQ 传递函数 10bit 静态元数据。它是目前兼容性最好的 HDR 基线格式几乎所有 HDR 设备都支持。缺点是静态元数据对整部片子一视同仁遇到明暗反差极大的片子比如一半是夜景一半是雪景用一套参数压全片总有一半吃亏。4.2 动态元数据逐场景调整的思路动态元数据的想法很直接既然一部片子里每个场景的亮度分布差别很大那就给每个场景甚至每一帧单独提供元数据让播放端按当前场景的特性做映射。这样夜景不会被过度提亮雪景也不会被过度压缩。实现上有几种路径差异主要在元数据是存在文件里还是随视频流传输、以及是否向下兼容。有一类是专有的商业方案需要整条链路内容、播放器、显示设备都支持才能发挥兼容性差但效果上限高。另一类是在 HDR10 基础上做扩展把动态元数据附加进去不支持扩展的设备会自动回落到静态元数据的 HDR10 基线。后者的思路更讨巧兼容性友好代价是效果没有专有方案那么极致。对普通用户来说这件事的实操意义是如果你的设备不支持动态元数据那这类内容在你这里就是普通 HDR10不用纠结。如果你支持那要注意播放链路里每一环都得放行中间任何一个环节不认这个元数据它就会被丢掉效果退回基线。很多人觉得“动态元数据没用”查下来是播放器把它吃了。4.3 几条路线的对比把常见路线放一张表里对照比文字描述清楚路线传递函数元数据兼容性典型适用场景HDR10 基线PQ静态极好几乎全支持通用分发、流媒体HDR10 扩展动态元数据PQ动态可回落好不支持则回落基线高品质流媒体、新片HLGHLG通常不带极好SDR 设备也能看广播、直播、体育专有动态方案PQ动态全链路要求差需授权和全链路支持高品质影碟、特定生态这张表的用法是拿到一个文件先看它属于哪一行就知道它对你的设备有什么要求。比如一个 HLG 的文件在老旧设备上也能放只是效果打折一个专有方案的文件在不支持的播放器上可能直接偏色或者拒播。提示不要迷信“格式越高级效果越好”。如果片源本身是 8bit 拉伸的套上再高级的元数据也没用反过来一个制作规范的 HDR10 基线片子在支持良好的设备上观感可以非常出色。5. 实操判定素材、转码与验证理论说完了这一节全是能直接抄的东西。我按实际操作顺序排先判定素材到底是什么再决定怎么处理最后验证结果对不对。工具以命令行工具为主因为参数透明、可复现图形界面工具的原理是一样的只是把参数藏在界面里。5.1 先用 ffprobe 把素材看穿拿到任何素材第一步永远是读标签不要凭文件名或者体积猜。命令很简单ffprobe -v error -select_streams v:0 \ -show_entries streamcodec_name,profile,width,height,pix_fmt,color_space,color_transfer,color_primaries,color_range,bit_rate,r_frame_rate \ -of defaultnoprint_wrappers1 input.mkv看输出里的几个关键字段。pix_fmt是yuv420p10le说明 10bityuv420p是 8bit。color_transfersmpte2084是 PQarib-std-b67是 HLGbt709是 SDR。color_primariesbt2020是宽色域bt709是标准色域。正常 HDR10 的组合应该是yuv420p10lebt2020smpte2084bt2020nc。只要有一个不匹配就要追问为什么。我遇到过的几种情况pix_fmtyuv420p但transfersmpte20848bit 标 HDR几乎肯定是拉伸出来的假 HDR。transfersmpte2084但primariesbt709标签混乱要么是转换时漏改要么是制作不规范。三个标签全是unknown封装时没写播放端只能猜这种最容易出问题需要手动指定。如果标签缺失ffprobe读不出来还可以用抽帧加统计的方式反推。下面这条命令能算出整段视频的平均亮度YAVG粗略判断内容和标签是否匹配ffmpeg -i input.mkv -vf selectnot(mod(n,120)),signalstats,metadataprint:keylavfi.signalstats.YAVG -f null - 21 | head -40如果标签写着 PQ但抽出来的 YAVG 大量集中在 0.4 到 0.5 这个区间10bit 码值 400-500 对应 PQ 下大概 50-100 nit说明内容确实在 SDR 亮度范围内很可能是假的。5.2 编码参数与主控显示描述如果是自己做 HDR 编码x265 是目前最常用的选择。关键参数有三组一个都不能省。下面是一条我常用的命令行骨架ffmpeg -i input.mov \ -c:v libx265 -preset slow -crf 18 \ -pix_fmt yuv420p10le \ -x265-params hdr101:colorprimbt2020:transfersmpte2084:colormatrixbt2020nc:\ master-displayG(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1):\ max-cll1000,400:hrd1 \ -color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc \ -c:a copy output.mkv几个参数的含义和取值依据master-display里的色度坐标要和调色监视器的实际参数一致不是随便填。常见的 BT.2020 原色坐标是 R(0.680, 0.320)、G(0.265, 0.690)、B(0.150, 0.060)乘以 50000 取整就是上面那串数字。L 的第一个值是母版峰值亮度乘 10000比如 1000 nit 写 10000000第二个值是最小亮度乘 100000.0001 nit 写 1。填错会导致播放端算错映射曲线。max-cll的两个值要基于实际内容统计不能拍脑袋。理想做法是用工具扫一遍全片取单帧最大亮度和帧平均亮度的最大值。粗略做法是抽样统计或者按母版峰值给一个保守值。标高了画面发灰标低了高光被削两种都难看。hrd1是打开 HRD 信息某些播放设备依赖它做缓冲判断不加可能导致卡顿。这个参数在小文件上看不出差别大文件上有用。5.3 把 HDR 回落到 SDR 的色调映射这是实操里最难的一步也是最容易做砸的一步。HDR 转 SDR 不是简单降亮度而是要把 1000 甚至 4000 nit 的动态范围压缩进 100 nit 的容器里同时尽量保持观感。核心是色调映射算法和参考白的选择。用 zscale 滤镜链是目前命令行里最可控的做法ffmpeg -i input_hdr.mkv \ -vf zscaletlinear:npl100,formatgbrpf32le,\ zscalepbt709,\ tonemaptonemaphable:desat0,\ zscaletbt709:mbt709:rtv,formatyuv420p \ -c:v libx264 -crf 18 -preset slow \ -color_primaries bt709 -color_trc bt709 -colorspace bt709 \ output_sdr.mkv拆开看每一步在干什么。第一步zscaletlinear:npl100把 PQ 曲线还原成线性光npl指定参考白 100 nit意思是“把 100 nit 映射成 SDR 的白色”。第二步转到浮点 RGB避免中间过程量化损失。第三步zscalepbt709做色域转换把 BT.2020 的颜色映射到 BT.709 边界内。第四步tonemap做动态范围压缩算法有 hable、mobius、reinhard、clip、bt2390 几种可选。最后转回 YUV 4:2:0 并打上 SDR 标签。算法怎么选我的经验是这样的hable压缩感强暗部保留好适合大部分电影缺点是饱和度会掉一点可以用desat0关掉额外的去饱和。mobius相对温和高光滚降自然适合本身亮度不极端的片子。bt2390是标准里定义的算法最“正确”但观感偏平适合需要严格对照的场合。clip就是硬切除了快速预览不建议用于交付。npl这个参数值得单独说。它决定了“多亮算白”。设成 100 是标准做法但如果你发现成片整体偏暗可以适当提到 150 或 200让中间调亮起来如果偏亮发灰就降到 80。这个值没有绝对正确答案取决于片源特性和目标观众的观看环境。我一般的做法是抽三到五个典型场景日景、夜景、逆光、室内各出一版对比选一个平衡点而不是只看一帧。5.4 验证截帧、波形与亮度统计转完之后必须验证别直接交付。三个检查动作五分钟能做完。第一重新ffprobe一遍确认标签是bt709bt709bt709yuv420p别出现 HDR 内容套 SDR 标签这种四不像。第二抽几个关键帧肉眼对比特别是高光区窗户、灯、天空有没有被压成一片死白暗部有没有糊成一团。第三用signalstats看亮度分布SDR 内容的 YAVG 正常应该在 90 到 140 之间8bit 码值YMAX 接近 235 说明高光保留得当如果 YMAX 长期卡在 200 以下说明映射压得太狠。ffmpeg -i output_sdr.mkv -vf selecteq(n,300),signalstats,metadataprint -vframes 1 -f null -这一步看似繁琐但能抓住大部分问题。我有一次偷懒没验交付后对方反馈“暗场看不见东西”回头一查tonemap 用了clip暗部直接被切掉了。重做了两小时。从那以后验证这一步我再也没省过。6. 播放链路与显示端为什么效果总对不上内容做对了播放端出问题的概率依然很高。HDR 的播放链路比 SDR 长涉及解码、色彩管理、系统输出格式、显示器映射四五个环节每一环都可能出错而且症状相似很容易误判。这一节按链路顺序说方便你按症状定位。6.1 硬件解码与色彩管理解码本身通常不是问题现代设备的硬解都支持 HEVC 10bit Main10 Profile。真正的问题是解码后的色彩管理由谁负责。理想的分工是解码器只负责还原数据播放器负责把数据按标签解释成正确的颜色系统负责把颜色送到显示设备显示设备负责最终的 tone mapping。现实里这个分工经常被打破。有些播放器会自己做 tone mapping有些交给系统有些两者都做结果就是双重映射。双重映射的典型症状是画面发灰、对比度低、高光没有力度看着像隔了一层雾。判断方法很简单找一个已知的 HDR 演示片最好是自带亮度标尺的那种在播放器里关掉“HDR 色调映射”选项对比开关前后的画面。如果关掉之后画面明显更通透说明之前是双重映射。还有一个隐蔽的问题系统输出格式。有些系统在开启 HDR 输出后会把桌面和所有内容都按 HDR 输出SDR 内容被“提升”到 HDR画面会偏灰。正确做法是让系统根据内容自动切换或者手动在播放 HDR 内容时开启。这个设置在系统显示设置里通常叫“HDR 开关”或者“自动 HDR”。6.2 系统 HDR 开关与假 HDR假 HDR 这个坑值得单独讲因为它太常见了。三种典型形态第一种8bit 拉伸。拿 SDR 素材转成 10bit标签改成 PQ/BT.2020元数据随便填。这种文件在支持 HDR 的设备上会触发 HDR 模式但因为内容本身没有高光信息画面会显得平淡甚至偏暗暗部还会因为位深转换出现色带。第二种容器套壳。内容完全是 SDR封装时把色彩标签改成 HDR本质是欺骗播放端。播放端按 PQ 解释画面整体会暗一大截因为 SDR 的码值在 PQ 下对应的亮度低得多。前面算过SDR 白点 235 在 PQ 下大概只有 100 nit 出头播放端如果按 1000 nit 的母版去映射画面就废了。第三种元数据虚标。内容是真的 HDR但 MaxCLL 标成 4000实际最高只有 800。播放端按 4000 做映射把本来不需要压的部分也压了画面发闷。这种最隐蔽因为文件确实有 HDR 内容只是参数错了。识别方法还是那套ffprobe看标签组合signalstats看实际亮度分布两者对照。标签说 PQ 但亮度分布集中在 SDR 区间就是假的标签说 4000 nit 但抽帧统计最高只到 700就是虚标。6.3 显示器能力与 tone mapping 的取舍最后一环是显示设备。这里有个残酷的现实大部分消费级 HDR 显示器的峰值亮度远低于内容母版所以 tone mapping 是必需的不是可选的。区别只在于由谁做、做得好不好。显示器自己做的 tone mapping质量取决于厂商调校。有些设备的“HDR 模式”其实只是把背光拉满、对比度调高根本不做真正的映射结果就是高光过曝、暗部死黑。有些设备做得好能根据内容元数据动态调整。判断方法播放一段带高光细节的测试片比如阳光下的水面、舞台灯光看高光区是不是还有纹理。如果一片纯白说明映射做得差或者根本没做。播放器做的 tone mapping可控性更好因为你能调参数。缺点是不同播放器的算法差异大同一个文件在两个播放器上观感可能完全不同。我的建议是只让一个环节做 tone mapping其他环节全部设成直通。具体是让播放器做还是让显示器做取决于哪个质量更好这需要你实际对比。我的经验是桌面环境让播放器做客厅环境让显示器做因为客厅的操作成本高用户不会去调参数。还有一个参数值得提显示器亮度设置。很多人为了“HDR 效果”把亮度拉满结果是 tone mapping 的输入范围变宽中间调被压得更狠画面反而更平。正确的做法是把显示器亮度设在一个舒适观看的水平让 tone mapping 在合理的范围内工作。这个值因人而异我的习惯是在暗环境里把峰值亮度设到设备能力的七成左右观感最平衡。7. 常见问题与排查速查前面几节把原理和流程都铺开了这一节收敛成可以随时查的东西。我按“症状 → 可能原因 → 验证方法”的顺序组织遇到问题直接对号入座能省掉大量试错。7.1 症状到原因的反查思路排查的核心逻辑是分段隔离把链路切成内容、解码、播放器、系统、显示五段每段单独验证。先确认内容本身没问题ffprobe 标签自洽、抽帧亮度合理再确认解码没问题换个播放器试试再确认播放器设置关掉所有增强选项再确认系统输出HDR 开关状态最后确认显示器用已知正常的片源测试。这个顺序不能乱否则会在错误的环节浪费大量时间。举个真实例子。有位朋友反馈他的 HDR 片子“整体发暗暗部全黑”。我让他按顺序查第一步 ffprobe标签正常第二步换播放器症状一样排除播放器第三步看系统发现系统 HDR 输出是关闭的但播放器强制输出 HDR 信号系统又把它当 SDR 二次转换亮度被压了两次。打开系统 HDR 自动切换问题解决。整个过程十分钟如果一开始就去调显示器参数可能调一晚上也调不对。7.2 速查表症状最可能的原因快速验证画面整体发灰、像蒙雾双重 tone mapping关掉播放器的 HDR 映射选项对比画面整体偏暗、暗部死黑系统 HDR 未开启或标签误导检查系统 HDR 开关ffprobe 看 transfer高光一片纯白无纹理显示器映射差或 MaxCLL 虚高换设备对比检查元数据暗部出现一圈圈色带8bit 编码或位深不足ffprobe 看 pix_fmt颜色过饱和、荧光感色彩矩阵标错检查 color_space 是否为 bt2020nc肤色发黄或发青白点或色域转换错误检查 primaries 与转换矩阵红色边缘发糊4:2:0 色度采样损失看是否多次转码检查 pix_fmt播放卡顿、掉帧硬解不支持或码率超带宽换软解测试看码率峰值HLG 内容偏暗播放端按 PQ 解释检查 transfer 是否为 arib-std-b67同一文件两台设备观感差异大各自 tone mapping 策略不同统一映射责任方这张表覆盖了我实际遇到过的大部分情况但排查时别死套症状可能叠加。比如“发灰 色带”同时出现可能是假 HDR 加 8bit 双重问题得分开解决。7.3 几个踩过的坑第一个坑是过度相信文件名。早期我拿到标着“HDR”的文件就直接按 HDR 流程处理结果有一批是拉伸的转出来颜色全错。后来养成习惯任何文件先 ffprobe两秒钟的事能避免几小时的返工。第二个坑是转码链太长。有一次做多语言版本同一份素材在四五个工具之间来回导每次都是 4:2:0 进 4:2:0 出最后成片红色区域糊得厉害。教训是中间环节尽量用高位深、高采样的格式最后一步才降到分发格式。第三个坑是元数据凭感觉填。刚开始做 HDR 编码时MaxCLL 随手填 1000结果有几部片子在暗环境观看时高光被压得没细节。后来老老实实用工具扫全片统计虽然多花十几分钟但成片质量稳定得多。第四个坑是以为设备支持就万事大吉。有台设备标称支持 HDR10实际映射算法很粗糙高光全削。这种情况没法通过参数解决只能换设备或者在播放器端做映射。买设备前最好带测试片去实测别只看参数表。最后分享一个我觉得最有用的小习惯建立一个自己的测试片库包含日景、夜景、逆光、高饱和、细线条、暗场渐变这几个典型场景每段三十秒左右带正确的 HDR 标签。每次改设置、换设备、做转码都拿这几段过一遍五分钟就能判断链路是否正常。这个习惯帮我抓住了至少三次隐蔽的配置错误比任何理论都管用。
