做视频处理这几年HDR转SDR一直是个绕不开的活儿。不管是做影视字幕压制、短视频二次分发还是给播放设备不支持的片子重新编码FFmpeg这套颜色转换命令都是最顺手、也能把细节抠到极致的方案。今天我把这套实战里反复打磨过的 HDR 转 SDR 命令、参数规律和踩坑记录完整整理出来希望对正在折腾 HDR 片源的朋友有实际帮助。1. 为什么需要把HDR转成SDR播放环境、压制场景与兼容性很多刚接触HDR的朋友会有一个疑问片源明明是P3色域、10bit色深、动态范围更广为什么要把好东西转成SDR道理其实很简单——不是所有屏幕都能还原HDR的光影层次。普通电脑显示器、大部分办公笔记本、很多手机屏幕出厂默认都是BT.709色域、8bit色深遇到HDR视频没有做正确的色彩映射要么画面灰成一片要么高光过曝到没法看。1.1 哪些场景下必须转SDR旧设备播放兼容家里的电视是几年前买的不支持HDR解码强行播放HDR片源会出现灰蒙蒙的色调暗部细节全丢。音视频混流与二次剪辑剪辑软件对HDR的支持到现在也不是全部流畅很多编辑流程里需要先把素材转成SDR方便调色和轴对齐。字幕压制与在线分发B站、短视频、公众号视频很多平台对HDR视频处理得很粗暴要么自动拉灰要么色彩饱和度失真自己先转好SDR再上传更可控。截图与预览做视频截图、缩略图、对比图JPG/PNG本身就不认HDR元数据先转SDR再截才准。常见热词里有“谷歌浏览器HDR截图过曝”其实本质就是浏览器渲染HDR视频后截图保存时没做tone mapping直接把PQ信号当SDR输出高光当然变成一片死白。手动用FFmpeg转换并做色彩管理就完全绕开了这种尴尬。1.2 核心思路HDR与SDR是两套“色彩语言”HDR视频一般携带BT.2020色域、PQ或HLG传递函数、10bit甚至12bit色深SDR视频则是BT.709色域、BT.1886/2.4 Gamma传递函数、8bit居多。两者之间的关系可以用一个打比方来理解HDR像摄影师用RAW格式拍的宽动态照片SDR像JPG直出调整期间要决定哪些亮度区间压缩、哪些色彩保留、白点怎么重定标。FFmpeg转HDR到SDR本质上要做三件事色调映射Tone Mapping把PQ/HLG编码的高动态范围亮度映射到SDR的0-100 nit范围。色域转换Gamut Conversion把BT.2020广色域的色彩坐标转换到BT.709色域。传递函数转换把PQ或HLG对应的EOTF转换成SDR的Gamma曲线。这三步复合在一条FFmpeg命令里完成很多人直接把zscale参数一丢就完事结果出来颜色怪怪的就是因为漏了 色彩矩阵、primaries和transfer 这三弟兄的配合。2. FFmpeg HDR转SDR命令速览一条可复制的完整命令先直接上菜这条命令是我目前实压过大量HDR10和HLG素材后色彩表现和细节保留都比较均衡的方案。目标SDR采用BT.709色域、BT.709矩阵、2.4 Gamma适合绝大多数显示器与网络在线视频平台。ffmpeg -i input.mkv -map 0:v:0 -map 0:a? -map 0:s? \ -vf zscaletlinear:npl100,formatgbrpf32le,zscalepbt709,tonemaptonemaphable:desat0,zscaletbt709:mbt709:rtv,formatyuv420p \ -c:v libx264 -preset slow -crf 18 \ -c:a copy -c:s copy \ -color_primaries bt709 -color_trc bt709 -colorspace bt709 \ -movflags faststart output_sdr.mp4这条命令表面上不复杂但每一段都有讲究。如果第一次跑可能看不太懂zscale里的一堆缩写我下面逐参数掰开讲。2.1 命令分段拆解-map 0:v:0只取第一个视频流避免有些MKV里有多个视频轨比如导演评论视频轨造成干扰。-vf滤波器链zscaletlinear:npl100这一步把输入信号的传递函数从PQHDR10或HLG拉到线性光域。npl100表示把100 nit当作名义峰值亮度nominal peak luminance这个值跟片源的实际峰值不一定严格相等但对大多数消费级HDR10内容100是安全通用值。如果用了支持HDR的监视器或者确定源是1000 nit的可以调整为更高但转SDR后差别不大我一般保持100。formatgbrpf32le线性光域后的数据必须转成32位浮点GBR平面格式后续的色域转换和tone mapping如果不用float精度会在压缩映射过程中出现banding和色阶断层这个是新手最容易忽略的一步。zscalepbt709把色彩primaries从BT.2020转成BT.709。这里只转了primaries矩阵和传递函数还在后面单独设置这也是FFmpeg颜色转换比很多图形界面工具更可控的地方。tonemaptonemaphable:desat0HDR到SDR的核心压缩算法。hable是Filmic效果的曲线之前做过游戏渲染的朋友应该不陌生高光过渡更柔和不生硬。desat0表示色度不额外去饱和。当亮度被大幅压缩时有些人会感觉色彩过浓这时候可以把desat调到0.5或1.0试感觉。要注意此处的tonemap参数名有点重复tonemaptonemaphable是在FFmpeg 4.3以后引入的书写方式。zscaletbt709:mbt709:rtv,formatyuv420p信号重新编码为BT.709传递函数、BT.709矩阵、视频范围tv最后转到yuv420p便于用libx264压制。这个顺序不能乱先转传递函数再定矩阵和range最后做像素格式转换否则会丢色彩精度。-c:v libx264 -preset slow -crf 18视频编码用x264质量优先模式crf 18在视觉上接近无损片源噪点多的话可以适当放宽到20。-c:a copy -c:s copy音频和字幕流直接复制不改编码不浪费时间。-color_primaries bt709 -color_trc bt709 -colorspace bt709这三个标签会写进输出文件的元数据。播放器VLC、PotPlayer、MPC会优先读这几个标签来决定色彩解读方式。忘了加上这三行画面对但色彩空间标记还是BT.2020就会出现播放器和渲染器不知道该用哪套颜色管理体系又灰又淡。2.2 参数选择背后的逻辑很多人会照着网上命令抄结果发现色调不对就开始胡乱调参数。这里把最关键的两个选择逻辑讲清楚第一是为什么用zscale而不是老式的scale。scale滤镜只能改分辨率和像素格式不具备色彩管理能力。FFmpeg的zscale封装了z.lib库可以做到primaries、transfer、matrix、range的细粒度变换是HDR到SDR转换的事实标准。第二是为什么用tonemaphable而不是tonemapreinhard或tonemapbt2390。reinhard是全局映射暗部提亮明显、局部对比弱bt2390是BT.2390标准里的EETF映射理论上更接近专业监视器的HDR到SDR转换但对普通视频观感可能偏暗hable的S曲线在保留中灰度对比度方面更有优势更适合在线视频这种“看着舒服”的场景。我实际对比下来hable细节不丢、色彩不过是综合首选。3. 色调映射、色彩矩阵与传递函数为什么不能直接转把HDR视频直接压缩成SDR而不做颜色处理效果就是画面灰暗、高光糊成一片。原因我刚才提过HDR和SDR各自有独立的颜色编码体系必须做完整的数学变换而不是字节层面的简单降级。这一节深入讲讲颜色转换的具体过程和参数背后涉及到的原理理解了这个你以后遇到任何转完颜色奇怪的视频都能自己排查。3.1 亮度信号的处理从PQ到GammaHDR10使用PQPerceptual Quantizer感知量化器也就是SMPTE ST 2084标准。PQ的设计目标是把人眼可感知的亮度范围0.0001到10000 cd/m²编码到12bit或10bit有限码值里色彩分布符合视觉感知阈值特性而不是线性编码。SDR使用Gamma 2.2或者Gamma 2.4传递函数亮度信号与电压或者说数码值与显示亮度呈幂律关系。从PQ转到Gamma核心操作就是把PQ码值对应的线性亮度经过tone mapping压缩到SDR亮度范围再按Gamma曲线做编码。FFmpeg命令里的zscaletlinear把PQ转到线性光tonemap在线性光域里做动态范围压缩最后再zscaletbt709回到非线性编码域。如果跳过中间的线性光转换直接对YUV的Y分量做范围映射高光层次的区分度会被大大压扁。3.2 色彩信号的处理真正决定“颜色对不对”的隐藏变量HDR视频的BT.2020色域色彩范围比BT.709大得多。BT.709的绿色坐标是(0.300, 0.600)BT.2020的绿色坐标是(0.170, 0.797)同一颗像素的RGB码值在这两个色彩空间里指代的实际颜色是不同位置的。转换过程通俗说就是BT.2020的三角形比BT.709大要把大的三角形压到小的三角形里面需要做矩阵运算。zscalepbt709干的就是这件事但是要注意矩阵运算不是简单地把RGB三个分量等比缩放而是要做色度适应chromatic adaptation。如果片源是HDR10一般建议用BT.2020到BT.709的标准矩阵FFmpeg会自动套用但如果你加了formatgbrpf32le在先就要确保转换过程在浮点域里做否则很容易在低亮度区域产生色块。这里还牵涉到一个经常被忽视的参数matrix。视频流在YUV域里的颜色是用矩阵来关联RGB和YCbCr的。HDR视频常用bt2020nc矩阵SDR一般用bt709矩阵。光转primaries和transfer不转matrix最后输出虽然是BT.709颜色但是YUV数学关系还留在BT.2020播放器很容易识别成“另一个色彩空间”出来的颜色是脏的、灰的甚至红绿偏移。这也是我为什么一直坚持在命令末尾既要设zscalembt709又要加-colorspace bt709标签两处都用BT.709矩阵把“计算域”和“标签域”统一起来。3.3 限制范围与完整范围8bit输出的最后一道坎视频编码里YUV有两种rangetvlimited range16-235和pcfull range0-255。网络视频平台和大多数电视播放使用的是tv range电脑显示器默认不一定。FFmpeg转换时如果原本片源是tv range而你输出成pc range会造成黑位发灰、白色限幅看起来像蒙了一层雾。HDR转SDR命令里zscalertv就是指定输出为tv range同时也需要在最后的formatyuv420p之前确认输入的range与之后的编码标签一致。如果不放心可以在压完之后用ffprobe查看输出的色彩信息这我在后面常见问题里会写。一句话总结HDR转SDR不是色彩降级而是色彩再映射。每一步参数的顺序、精度和标签都会影响最终结果缺一环就是偏色。4. 实操验证从HDR10到SDR的完整转换流程工具准备和命令都齐了下面走一遍实际转换流程。我带了一个真实场景一部4K HDR10电影片段封装是MKV视频流是HEVC 10bit音频是DTS-HD MA字幕是PGS图形字幕。4.1 先探测片源信息FFmpeg安装方法就不细说了各平台都有现成的包管理器。拿到片源后第一步永远是探测ffprobe -v error -show_streams input.mkv | grep -E codec_name|profile|pix_fmt|color_primaries|color_transfer|color_space看输出里有没有类似这样的内容codec_namehevc profileMain 10 pix_fmtyuv420p10le color_primariesbt2020 color_transfersmpte2084 color_spacebt2020nccolor_transfersmpte2084表示HDR10PQ如果显示arib-std-b67则是HLG。不同传递函数的转换命令略有差异HLG理论上只需要做OOTF处理不需要像PQ那样严重的tone mapping但用同一条hable转换也能得到可观结果细节会有一点损失。如果ffprobe输出里没有颜色信息说明片源容器里没写标签这种情况比较麻烦只能根据经验推断4K HEVC Main 10最常见的就是HDR10可以先按HDR10处理但输出前一定要肉眼看完几个亮暗场景。4.2 实际执行转换以mkv封装、5.1声道、两条字幕为例输入下面的命令前面2.1的命令基础上增加了更多流的映射和音轨选择ffmpeg -i input.mkv \ -map 0:v:0 \ -map 0:a:0 \ -map 0:s? \ -vf zscaletlinear:npl100,formatgbrpf32le,zscalepbt709,tonemaptonemaphable:desat0,zscaletbt709:mbt709:rtv,formatyuv420p \ -c:v libx264 -preset slow -crf 18 \ -c:a copy -c:s copy \ -color_primaries bt709 -color_trc bt709 -colorspace bt709 \ -movflags faststart \ output_sdr.mp4如果你的视频源是HLG比如很多直播、广播级HDR素材可以把zscaletlinear后面加一个:min0:max1000限制输入亮度范围或者改用下面专门针对HLG的映射方式-vf zscaletlinear,formatgbrpf32le,zscalepbt709,tonemaptonemaphable:desat0,zscaletbt709:mbt709:rtv,formatyuv420p两者差异主要在于npl参数。HLG没有固定峰值亮度用HLG参考监视器标准往往设定为1000 nit参考白映射到SDR时直接线性缩放即可。4.3 验证输出结果压完后用ffprobe再看一遍输出文件的颜色属性ffprobe -v error -show_streams output_sdr.mp4 | grep -E codec_name|pix_fmt|color_primaries|color_transfer|color_space期望结果codec_nameh264 profileHigh pix_fmtyuv420p color_primariesbt709 color_transferbt709 color_spacebt709这三项如果不全对播放器就极大概率误判色彩。另外用播放器截图对比几个典型场景白天逆光场景高光部分不能过曝成纯白云层或窗户边缘要有层次。暗光室内场景黑位不能糊成一片椅背轮廓、衣服纹理在暗部也要能分辨。人物肤色不能偏黄、偏绿、发灰。HDR转SDR最容易出的问题就是肤色变蜡黄这通常是因为desat参数设太高或者primaries没转对。5. 常见问题与排查技巧实录实际使用中踩过的坑比官网文档多得多很多问题让人头疼。这里把最典型的几个问题整理出来方便你有针对性地排查也避免在同一个地方反复栽跟头。5.1 高光过曝暗部死黑现象转出来的视频在太阳、灯光这类高光区域变成纯白色块暗部又黑得没有细节。原因95%的情况是tone mapping没做或参数不当。如果命令里漏了tonemap亮度范围直接从PQ压缩到Gamma高光必然过曝。如果tonemaphable:desat0还过曝试着把npl值调低比如从100改为75或者改用tonemapreinhard它的高光压缩更激进。另一个细节如果原HDR片源峰值亮度标了4000 nit而npl只设了100映射到SDR时高光信息会先被cut掉一部分也会有过曝感。这时候可以把npl调到203或更高的值但我不建议无脑调高实际观感才是标准。5.2 颜色偏灰、饱和度低现象转出来颜色发白像隔着一层雾整体饱和度明显不够。原因这个现象多半是primaries没转或者标签没写对。最常见的是跳过zscalepbt709花了大功夫做亮度映射颜色空间却留在了BT.2020播放器识别成BT.2020后用SDR伽马渲染色彩自然发灰。排查手法用ffprobe检查输出的color_space。如果是bt2020nc说明只改了transfer没改matrix和primaries命令里的mbt709和-colorspace bt709没生效。5.3 转换后画面偏绿或偏紫现象整体色偏明显尤其肤色和草地场景绿色偏得很诡异。原因这种色偏大多数是因为转换链路中做了两次色彩矩阵运算或者在RGB和YUV之间来回切换时损失了精度。比如说先formatyuv420p又转zscalepbt709顺序反了——先降位深和采样格式再做色彩转换色彩精度已经丢了一截出来就会有色偏。正确顺序永远是先转线性光域保持在float RGB做完primaries转换和tonemap最后才转回YUV再降位深和采样。5.4 转换结果还是有轻微banding色带现象天空、暗背景这类平滑渐变区域出现一圈一圈的色带像压缩过度的GIF。原因10bit HDR转8bit SDR色阶直接减少了一大截渐变区域必然会有banding风险。降低码率或crf值、加噪点dithering是两条常见解决路径。FFmpeg里可以通过format滤镜加dither参数比如formatyuv420p:default也可以换成yuv420p10le输出然后用更高位深保存并最后交给x264编码时开启-x264-params psy-rd1.0:0.0来缓解。小成本方案是在vf链最后加一个轻微噪声,noisealls3:allft注意这会让文件体积变大要权衡。5.5 转换后播放器显示“HDR”字样现象明明转了SDR但PotPlayer、电视等设备还是识别成HDR。原因颜色标签问题。如果只是做了像素转换但没写-color_primaries bt709 -color_trc bt709 -colorspace bt709元数据就还保留HDR标记。在MKV里还可能多个轨道都带着各自的标签。解决重新封装时显式设置颜色标签或者用ffmpeg -i output_sdr.mp4 -c copy -color_primaries bt709 -color_trc bt709 -colorspace bt709 output_sdr_fixed.mp4重新洗一遍标签。5.6 常见问题速查表现象可能原因解决方向高光过曝没做tonemap或npl过高加入tonemap适当降低npl整体发灰缺primaries转换或标签没写检查zscale和-color_*标签偏绿/偏紫转换顺序错误或位深丢失先浮点RGB后转YUV暗部死黑映射曲线不合适尝试reinhard或调整desat严重banding10bit转8bit色阶不足输出10bit或加dither播放器仍识别HDR标签未更新手工覆盖color标签6. 进阶玩法批量处理与局部调整思路视频是批量素材时一条条手写命令效率太低。我一般会写一个简单的批处理脚本Windows上就是batmacOS/Linux上用shell。循环遍历文件夹下的所有mkv自动转换并输出到新目录。这里给一个Linux/macOS bash示例#!/bin/bash for f in *.mkv; do ffmpeg -i $f \ -map 0:v:0 -map 0:a? -map 0:s? \ -vf zscaletlinear:npl100,formatgbrpf32le,zscalepbt709,tonemaptonemaphable:desat0,zscaletbt709:mbt709:rtv,formatyuv420p \ -c:v libx264 -preset fast -crf 19 \ -c:a copy -c:s copy \ -color_primaries bt709 -color_trc bt709 -colorspace bt709 \ sdr_${f%.mkv}.mp4 done批量压片子时preset slow可能一集电影就要几小时preset fast和crf 19是效率和画质的折中我看在线视频素材用这个组合很多。如果只想对某个时间段的片段转SDR可以加-ss和-tffmpeg -ss 00:12:00 -t 60 -i input.mkv ...如果源文件是10bit HEVC想要转成10bit SDR保留更多色阶把最后的formatyuv420p换成formatyuv420p10le即可x264会以10bit模式编码兼容性上某些播放器需要注一下。6.1 局部色彩调整的想法命令里tonemap的desat参数适合全片整体去饱和如果只想对高光或暗部的色饱和度做调整可以用geq或者curves滤镜做局部曲线调整。但我的习惯是能用zscale和tonemap解决的就不要堆滤镜尤其是批量任务滤镜越多越难排查问题。6.2 进一步参考方向这篇主要讲HDR10到SDRHLG到SDR其实也有类似流程。如果你看到片源是BT.2020色彩空间但传递函数是HLG转换思路差别不大只是线性化和色调映射的峰值设定要按HLG标准来。学会这条FFmpeg命令就能灵活应付大部分HDR转SDR场景。我实际做批量转换时还有一个习惯每批片子转换后随机抽两三个时间点截图用快速看图软件对比原片和转出片的亮度直方图——直方图高光如果顶到右边边界基本可以断定高光有裁剪再回头微调npl和tonemap参数。这种“压完必须验证灰度分布”的工作习惯帮我避开了很多批处理时颜色集体翻车的坑。希望这篇文章也能帮你在HDR转SDR的路上少走几条弯路。