1. 先说结论播放器“自动转SDR”看起来能用但真要自己压一版还是要靠FFmpeg前阵子从网盘里翻出一部4K HDR片子兴冲冲接到客厅老电视上结果整画面灰得像蒙了一层雾颜色也过饱和。手机上看又觉得亮部刺眼、暗部一团黑。后来用FFmpeg HDR视频转SDR视频命令压了一版问题才彻底解决。今天这篇不谈玄学直接把我压了两年多、反复验证过的命令和思路拆开讲透顺便把我在HDR转SDR过程中遇到的偏色、过曝、发灰、色带这些翻车经历一并复盘。先说清楚为什么我不直接靠播放器的“自动转换”非要离线转码。播放器的实时转换有两个痛点一是性能4K HDR画面要实时做色调映射普通电视盒子、老显卡很容易掉帧拖进度条的时候更是明显二是不可控播放器内部用的映射算法、输出亮度、色彩空间你完全改不了遇到某些偏门素材它就是偏色你只能干瞪眼。而FFmpeg离线压一版画质稳定、参数可控、能批量处理交付给其他人看也不会因为设备不同出现观感差异。所以只要你经常处理HDR素材不管是电影、相机拍的HLG视频还是游戏录屏都值得把这条命令练熟。适合谁来参考如果你手头有HDR片源想给普通SDR屏幕或者老投影看如果你是视频创作者需要把HDR素材统一转成SDR交片或者你只是好奇FFmpeg色彩处理到底怎么回事这篇都能直接用。我会把概念部分尽量压缩到“够用”的程度重点放在命令和避坑上。2. 转码前必须理解的三件事EOTF、色彩空间、色彩体积HDR转SDR不是简单把画面调暗。你如果直接拿色阶/曲线工具硬拉出来的东西大概率是“看起来像HDR的SDR垃圾”。要正确定位问题得先明白三个基础概念EOTF、色彩空间、色彩体积。别怕都是能用人话讲清的。2.1 EOTF电光转换函数决定了“亮度”怎么编码EOTF全称是Electro-Optical Transfer Function解决的核心问题是“电压/数字值对应多少物理亮度”。SDR用的是BT.1886这条伽马曲线峰值亮度通常在100尼特左右而HDR10用的是PQ曲线SMPTE ST 2084它可以编码到10000尼特的亮度范围HLG用的是另一条混合对数伽马曲线兼容SDR显示专门为广播电视设计。为什么要分这么细因为同一个数字值在不同EOTF下代表的亮度完全不同。如果你把HDR10素材当SDR直接显示相当于拿一套错误标尺去读亮度结果必然是灰蒙蒙或者过曝。FFmpeg转码时第一步就是把输入信号的EOTF“翻译”成线性光这就是后面zscale里设置tlinear的原因。2.2 色彩空间Color Primaries决定了色域范围色彩空间规定了RGB三个原色的坐标位置简单理解就是调色盘有多大。SDR内容绝大多数使用BT.709色域覆盖范围大概是人眼可见光谱的三分之一左右HDR内容常用BT.2020能覆盖的可见色谱范围大约是BT.709的两倍以上。这也是为什么HDR电影里那些浓郁的红、绿、蓝在SDR屏幕上总显得发灰发旧——因为SDR的“调色盘”根本装不下那么多颜色必须做压缩映射。转SDR时通常要把BT.2020色域转换到BT.709色域这个动作在FFmpeg里由zscale的p参数完成。很多人忽略这一点只在亮度上做文章结果颜色依然不对。2.3 色彩体积比色彩空间更接近本质别被“体积”这个词吓到。色彩空间是二维的只管色域范围再加上亮度轴就变成了一个三维体积。HDR内容的色彩体积远大于SDR转码的终极目标是把一个更大的三维体积“装”进一个更小的容器里。亮度压缩由色调映射算法负责色域压缩由色彩空间转换负责两者必须配合。理解了这一点你再看网上那些“HDR转SDR只要加一句tonemap就行”的说法就知道有多片面了。正确的FFmpeg HDR转SDR命令本质上是一条完整链路解码输入的HDR信号 → 转为线性光 → 做色调映射压缩亮度 → 转换到BT.709色域 → 转回SDR的伽马曲线 → 编码输出。后面所有参数都围绕这条链路展开。项目SDR典型规格HDR10典型规格HLG典型规格峰值亮度约100尼特最高1000-4000尼特兼容SDR可到1000尼特以上传输函数BT.1886伽马PQST 2084HLGARIB STD-B67常用色域BT.709BT.2020BT.2020常见用途普通视频、电视节目流媒体、4K蓝光广播电视、相机HDR3. 这套压了两年多最靠谱的命令我逐参数拆给你看直接上我主力使用的命令模板。输入是常见的HDR10视频比如4K蓝光Remux输出是兼容性极好的H.265 8bit SDR MP4。注意这命令不是唯一答案但它是经过我大量对比之后最稳的一条稳定性优先于极限画质。ffmpeg -y -i input.mkv \ -map 0:v:0 -map 0:a? \ -vf zscaletlinear:npl100,tonemapbt2390:desat0,zscaletbt709:pbt709:mbt709:rtv,formatyuv420p \ -c:v libx265 -preset slow -crf 18 -tag:v hvc1 \ -color_primaries bt709 -color_trc bt709 -colorspace bt709 \ -c:a aac -b:a 192k output.mp43.1 滤镜链前半段先把HDR信号翻译成线性光关键在zscaletlinear:npl100。zscale是FFmpeg基于zimg库的高质量缩放和色彩空间转换滤镜这里我们不是用它缩放分辨率而是利用它做传输函数转换。tlinear的意思是把输入的PQ曲线信号转换成物理线性光这一步非常重要色调映射算法必须在线性光下计算否则在高光和暗部分别做非线性的压缩画面会出现色偏和过渡硬切。npl100是nominal peak luminance的缩写表示把多少尼特作为SDR输出的标称峰值亮度。这里设100就是告诉zscale后面我要把亮度压到100尼特这个SDR参考水平。如果你的目标屏幕峰值亮度只有80尼特可以相应调低但一般100尼特是BT.709 SDR的标准兼容性最好。3.2 滤镜链中段色调映射压缩动态范围tonemapbt2390:desat0是整条命令的核心。tonemap滤镜负责把线性光的宽广动态范围压缩到SDR能表达的范围内。bt2390是我目前最推荐的算法它源自HDR10规范里的SDR转换建议在高光滚落和整体画面对比度之间取得了很好的平衡。后面专门有一章讲算法选择这里先不展开。desat0这个参数值得单独说明。色调映射在压缩高光时容易出现色彩饱和度异常增高所以FFmpeg提供了desat参数做去饱和默认值是0.5。但我实测下来在bt2390算法下默认去饱和会让暗部和高光的颜色都有点发“灰”所以我把它设为0让颜色更纯正。当然这是个人口味你可以用0.5先压一版对比看看。3.3 滤镜链后半段转回BT.709并处理色度采样zscaletbt709:pbt709:mbt709:rtv这一步很多人会漏漏了就是灾难。它的作用是把线性光下处理完的画面转回SDR标准tbt709设置BT.709的传输函数pbt709把色彩原色从BT.2020映射到BT.709mbt709设置色彩矩阵rtv表示有限范围16-235。为什么矩阵也要显式声明因为HDR内容大多是BT.2020非恒定亮度矩阵bt2020nc如果只转了传输函数不转矩阵输出画面会产生诡异的绿色/紫色色偏。手动把三个参数全部指定就是不给FFmpeg留“猜”的余地保证输出元数据完整。最后formatyuv420p把像素格式统一成8bit 4:2:0这是最大兼容格式几乎所有播放器、电视、剪辑软件都能直接处理。3.4 编码器参数和容器元数据编码器用libx265CRF 18配合preset slow这是我在“体积、画质、耗时”三者之间的平衡点。CRF 18属于视觉无损区间再往小压体积也没明显提升反而浪费时间。如果你追求极限容量可以CRF 20到22但暗部渐变色带风险会增加。-color_primaries bt709 -color_trc bt709 -colorspace bt709这三项是写给容器和播放器看的元数据告诉它们“我是标准SDR视频请按SDR来渲染”。这一步不是可有可无很多播放器就是靠这几个标签决定要不要触发HDR模式。输出封装成MP4的话音频我建议重新编码为AAC因为原盘的DTS-HD、TrueHD音轨直接copy进MP4经常会遇到兼容性问题。追求无损就封装成MKV再把-c:a copy用上。有一点也要提醒杜比视界Dolby Vision里的Profile 5是单层融合格式普通FFmpeg命令经常解不出正确的颜色转出来大概率是偏紫的废片。遇到杜比视界资源先确认是不是Profile 5Profile 8还可以用类似命令试Profile 5建议直接放弃或者用专门工具处理。这个坑我踩过不希望你重复踩。4. 常见翻车现场偏色、过曝、发灰、色带逐个破案命令会给以后大问题才刚开始。每次评论区都有人问我“为什么我转出来灰蒙蒙”“为什么颜色紫了”下面几个问题是最高频的翻车现场附排查链路。4.1 过曝、死白、灰蒙蒙大概率是没做色调映射或者映射前没转线性光症状是画面高光一片死白或者整体发灰黑色不黑白色不白。最直接的原因是你把滤镜链写成了只做色彩空间转换# 错误示例 -vf zscaletbt709:pbt709:mbt709:rtv这样做等于把HDR的PQ信号直接套上BT.709的伽马曲线。PQ信号里编码的高光信息远超SDR能表达的100尼特你不做压缩所有超过标尺的部分全部被“削平”高光自然死白。而如果加了tonemap但没先zscaletlinear色调映射作用在非线性信号上计算出的压缩比例是错的整体观感就是灰蒙蒙的。排查时先确认滤镜链是不是完整包含了“转线性光→色调映射→转回BT.709”三段缺一段都不行。4.2 画面整体偏紫红色或者偏绿色彩矩阵不匹配基本实锤这个症状最常见的场景是片源明明标注HDR10转出来草丛变成紫色人脸像得了黄疸。根因是输入色彩矩阵和输出色彩矩阵对不上。HDR素材通常是bt2020ncSDR输出是bt709如果你在zscale最后一步只写了tbt709而漏了mbt709FFmpeg可能沿用输入的bt2020nc矩阵于是严重的色偏就出现了。还有另一种情况是输入文件本身色彩标签缺失被FFmpeg默认按bt709读那无论如何后面怎么转都救不回来。排查链路按这个顺序来先用ffprobe看输入的真实色彩标签ffprobe -v quiet -print_format json -show_streams -select_streams v:0 \ -show_entries streamcolor_primaries,color_trc,color_space,color_range,pix_fmt,width,height input.mkv重点看color_space是不是bt2020nccolor_range是不是tv。如果这些字段是unknown说明文件metadata不完整需要你在zscale输入端手动指定原始空间。举例你确认片源就是BT.2020、PQ、limited range但文件标签丢了可以这样强设-vf zscaletin:pbt2020:mbt2020nc:rtv,zscaletlinear:npl100,tonemapbt2390:desat0,zscaletbt709:pbt709:mbt709:rtv,formatyuv420p注意第一个zscale里tin表示传输函数保持输入原样也就是PQp和m设成BT.2020r设成tv。这样FFmpeg在后续转换时就能拿到正确的输入信息了。4.3 HLG素材被当成PQ处理暗部死黑高光却亮得刺眼如果你拿手机、相机拍HDR视频大概率是HLG而不是PQ。HLG的曲线设计初衷是兼容SDR相对于PQ它暗部更接近SDR观感。处理HLG素材时如果直接套用HDR10的PQ色调映射链路暗部会被过度压缩成死黑亮部又压得不够。排查方法还是看ffprobe里的color_trc字段如果是arib-std-b67或者显示HLG就说明是HLG素材。HLG转SDR我自己更倾向简化处理只做色彩空间转换不做激进的色调映射因为HLG本来就有SDR兼容性ffmpeg -i input.mkv -vf zscaletbt709:pbt709:mbt709:rtv,formatyuv420p -c:v libx265 -crf 18 -color_primaries bt709 -color_trc bt709 -colorspace bt709 output.mp4如果觉得高光还是刺眼再在中间加一个tonemapmobius:desat0做轻度压缩就够了。记住一个原则HLG和PQ是两套亮度标尺用错标尺才是画质崩坏的根源。4.4 暗部色带明显8bit输出和编码器参数共同背锅HDR素材本身是10bit甚至12bit转到8bit之后暗部渐变很容易出现一圈一圈的带状断层。罪魁祸首有两个一是输出格式固定成了yuv420p8bit二是CRF值开太高导致暗部被二次压烂。我常用的补救方案有两个。第一个是输出10bit的SDR视频现在绝大多数设备的解码能力已经支持10bit H.265哪怕输出SDR10bit的渐变表现也比8bit好太多。把滤镜链最后的formatyuv420p改成formatyuv420p10le同时确保libx265能接收10bit输入就可以。第二个是降低CRF从18降到16画质更稳但文件体积会明显增大。如果你必须输出8bit可以在zscale最后一步加上dither选项比如zscaledithererror_diffusion让量化误差变成细微噪声而不是显眼的色带。代价是暗部噪点会略增属于两害相权取其轻。5. 色调映射算法怎么选hable、mobius、reinhard、bt2390的实测感受很多教程只管给命令不解释算法结果就是大家换了个算法名就觉得是玄学。我专门把FFmpeg内置的几种色调映射算法拉出来做了横向对比素材是同一段4K HDR10演示片输出统一为1080p SDR只改tonemap参数。算法高光表现暗部细节整体风格我的推荐场景reinhard温和压缩容易整体发平保留一般平淡稳定几乎不出错快速批量、无人值守hable高光滚落优美电影感强暗部略有抬升对比很强偶尔发灰电影、剧情类内容mobius高光细节保留最多较好锐利但过渡稍生硬高光信息丰富的风光片bt2390均衡自然高光过渡平滑好最接近HDR源观感我的长期主力方案5.1 reinhard最稳妥的“老好人”reinhard算法属于经典色调映射数学上简单就是把超过阈值的亮度平滑压缩。它最大的优点是不会出大错但缺点是“存在感太强”——所有亮度都被压了一轮导致画面整体对比下降看起来有点“平”。如果你只是想把HDR素材快速压成可交付的SDR不在乎极致观感reinhard完全够用。5.2 hable电影感控的最爱但暗部要留意hable算法源自Uncharted 2游戏的色调映射曲线特点是对中间调和高光的处理非常“顺滑”高光滚落自然很多电影感调色都会手动模拟这条曲线。我实测下来hable对画面高光区域的保护确实好但暗部会被轻微拉亮导致原本应该深邃的黑色变得泛灰。如果你偏爱这种风格记得把desat适当调回0.2到0.3避免压暗后颜色过闷。5.3 mobius极限细节党首选mobius算法在处理高光细节时优势明显比如云层纹理、灯箱文字这些容易过曝的区域它能保留更多层次。代价是色调过渡不如hable平滑中间调偶尔会出现“生硬感”。如果你想最大限度保留画面信息不太在意“胶片感”mobius值得试。5.4 bt2390我最终长期使用的答案bt2390本身是ITU针对HDR转SDR应用场景给出的建议它结合了亮度自适应和色域映射的策略。用大白话说它会在压缩动态范围的同时尽量保持画面原有的明暗关系不会像reinhard那样把整体对比拉平也不会像hable那样把暗部抬灰。我在电影、纪录片、游戏录像上都做了对比bt2390的综合观感最接近在HDR显示器上看到的效果。所以我主力命令里默认就是bt2390。选算法的通用建议先用同一帧视频分别压出三到五张小样放到你最终要观看的那台设备上看。色调映射是主观体验参数表救不了审美。FFmpeg离线转码最大的优势就是方便做小样对比这个习惯值得养成。6. 批量转码与工程化小技巧别一部一部敲命令了当你手里有五部电影、三十条素材要转的时候一条条敲命令不现实。我自己的做法是写一个简单的bash脚本配合ffprobe做“先判断后处理”免得把SDR素材又当成HDR压一遍。6.1 批量循环脚本顺便把日志存下来#!/bin/bash mkdir -p sdr for f in *.mkv; do echo 正在处理: $f # 先用ffprobe判断亮度传输特性 trc$(ffprobe -v quiet -show_streams -select_streams v:0 \ -show_entries streamcolor_trc -of defaultnoprint_wrappers1:nokey1 $f) if [[ $trc smpte2084 || $trc arib-std-b67 ]]; then ffmpeg -y -i $f \ -map 0:v:0 -map 0:a? \ -vf zscaletlinear:npl100,tonemapbt2390:desat0,zscaletbt709:pbt709:mbt709:rtv,formatyuv420p \ -c:v libx265 -preset slow -crf 18 -tag:v hvc1 \ -color_primaries bt709 -color_trc bt709 -colorspace bt709 \ -c:a aac -b:a 192k sdr/${f%.mkv}.mp4 2 sdr/${f%.mkv}.log else echo 跳过非HDR文件: $f fi done几个细节说一下。-map 0:v:0 -map 0:a?的意思是只取第一个视频流和所有音频流避免原盘里的评论音轨、附加视频被混进输出。日志单独存sdr目录下批量压完如果哪部有问题直接查日志比在终端翻滚动快得多。判断条件是smpte2084PQ对应HDR10和arib-std-b67HLG这两个是当前HDR素材最主要的传输函数。6.2 先截一帧小样别急着压整片批量处理前我强烈建议先对每个原始文件抽一帧做预览验证。做法很简单ffmpeg -i input.mkv -ss 00:30:00 -frames:v 1 \ -vf zscaletlinear:npl100,tonemapbt2390:desat0,zscaletbt709:pbt709:mbt709:rtv,formatyuv420p \ preview.jpg选一个高光和暗部都丰富的画面比如夜景的城市航拍。几秒钟出图先看颜色正不正、高光有没有过曝、暗部有没有死黑确认没问题后再全片压。这一步能帮你省下大把重压时间尤其是碰到metadata标签不全的素材时。6.3 并行度控制与硬编码取舍批量转码最忌讳一股脑开十几个进程CPU直接打满系统卡到没法操作而且x265本身是多线程的过多进程并行还会互相抢内存。我的经验是物理核心数的一半比如8核16线程的机器同时跑3到4个FFmpeg进程最稳妥。每个进程内部x265会自动用多线程整体吞吐量反而更高。如果时间紧张可以试硬件编码器。比如Intel核显或者NVIDIA显卡把-c:v libx265换成-c:v h264_qsv或者-c:v hevc_nvenc。实测下来速度提升确实夸张但同码率下的画质和纯CPU的libx265相比还是有差距。我的原则是预览成片、社交媒体用硬件编码足够正式存档、给客户交付用CPU慢压。色彩处理滤镜链本身是CPU计算的硬件编码只接管最后压缩那一步这要提前有心理准备。6.4 内容命名为避免日后再踩坑输出文件名我习惯加上_SDR_709后缀比如原文件The.World.2025.4K.HDR10.mkv输出为The.World.2025.4K.SDR_709.mp4。别小看这个习惯素材一多你根本记不住哪部已经转过了。我在文件名里还会保留原始分辨率方便后续按需再压其他格式。最后再分享一个我踩过好几次的小技巧FFmpeg处理HDR转SDR的输出帧最好直接给编码器不要中间接其他滤镜。之前为了顺手做画中画、跑马灯我在滤镜链后面又加了overlay、drawtext这些滤镜结果FFmpeg为了兼容自动改变了像素格式颜色又出现轻微偏移。折腾了半天才定位到是滤镜顺序打乱了色彩空间。色彩转换相关的滤镜尽量放在整条滤镜链的最末端或者干脆分两步处理先转SDR存中间文件再做特效分开跑就没这个问题。