FFmpeg HDR转SDR完整指南：色调映射与色彩空间转换实战

做视频处理这些年，我遇到最多的一个问题就是“为什么HDR片源一到我电脑上就灰蒙蒙的”。原因很简单，你的显示器、播放器、剪辑软件很可能还在SDR通道里工作，HDR素材没有经过正确转换，直接被当成普通SDR输出，亮部和颜色自然全乱套。FFmpeg作为命令行工具，解决这类问题是绝对的强项，一条命令就能把HDR视频转成SDR视频，同时控制峰值亮度、色彩空间和色调映射曲线。今天我不打算只丢几条命令给你，而是把背后原理、参数怎么选、高光怎么保、颜色怎么不偏，全部拆开讲透。

1. 为什么需要HDR转SDR：从片源到播放的现实困境

1.1 HDR和SDR到底差在哪

要搞清楚怎么转，先得明白HDR和SDR的核心差异。SDR（标准动态范围）的显示标准基本停留在BT.709色彩空间，亮度范围大概在0.1到100尼特，绝大多数普通显示器、手机屏幕、在线视频平台都默认按这个标准工作。而HDR（高动态范围）走的是BT.2020色彩空间，亮度上限从几百尼特到几千尼特，色彩位深也更高，用的是PQ或HLG这类光电转换曲线。

乔一个直观类比：SDR像一张白纸上的水彩画，HDR则是同一张纸在强光下看，颜色更鲜艳、亮的更亮、暗的更暗。水彩的颜料还是那些，但纸的“动态范围”被拉大了。问题是，如果你把这张HDR“画”贴到一台根本不支持强光的普通显示器上，高光细节就全部溢出，暗部也糊成一片。

很多刚接触HDR片源的人会以为“HDR就是更亮更鲜艳”，结果压完SDR后颜色发紫、人脸像涂了腮红，高光一团白。这恰恰是因为没有做色调映射，而是直接把BT.2020的数值硬塞进BT.709的坐标里，等于把大画装进了小框，不裁边才怪。

1.2 不转换会出现的几种典型画质事故

不经过转换直接播放HDR视频，最常见的后果是画面整体变灰。原因在于SDR播放器读取到PQ曲线后，不知道要按PQ解码，只按Gamma曲线处理，整个画面的对比度会被强行压平，黑色变成深灰，白色变成浅灰，看起来像隔了一层雾。

第二种典型问题是颜色过饱和。HDR素材的色彩坐标范围比SDR大，如果播放器或剪辑软件没有做色彩空间转换，直接把BT.2020的信号当作BT.709输出，绿色会绿得发假、红色会红到刺眼，树叶和皮肤尤其明显。

第三种是谷歌浏览器播放HDR视频截图过曝，这其实就是浏览器渲染管线没有正确处理HDR元数据，亮部直接切到最高值，截出来的图就是一片死白。很多人因此怀疑是片源的问题，其实是显示链路里的色彩管理缺了一环。无论哪种情况，破局办法是一样的：用FFmpeg在离线环节做好HDR到SDR的转换，输出一份所有设备都能正常显示的SDR文件。

1.3 哪些场景最需要HDR转SDR

如果你只是在自己电脑上看HDR电影，电脑显示器又支持HDR，那确实不需要转。但下面这些场景几乎绕不开：

• 把HDR视频传到不兼容HDR的社交平台，比如普通上传接口，它们会压缩处理导致画面发灰。
• 做视频剪辑时使用的主要显示器还是SDR，剪辑预览和导出目标都是SDR。
• 给客户交付样片，对方在普通设备上看，你不转成SDR，对方看到的就是一副“坏画质”。
• 想对HDR视频做二次创作，比如剪辑、加字幕、压字幕，先把源转成SDR统一后面流程更容易。

我自己的习惯是，源文件保留HDR原始版本，所有用于预览、网络分发、样片的文件一律转成SDR。转出高质量SDR，最重要的一步就是选对色调映射和色彩转换命令。

2. FFmpeg做色调映射的核心原理与准备工作

2.1 为什么选择FFmpeg而不是图形化软件

很多剪辑软件和转码工具也内置了HDR转SDR功能，比如Premiere的Lumetri、Final Cut的色彩空间匹配，但它们的处理流程比较“黑盒”，你能调节的参数有限，而且只有在完整工程里才能操作。FFmpeg的优势是轻量、可控、可批量，一条命令就能跑完整个文件夹，不依赖图形界面。

再加上FFmpeg的滤镜链是显式定义的，每一步做什么、转换顺序是什么，都清清楚楚。这就意味着你可以根据片源实际情况微调参数，而不是被软件预设绑死。对经常处理视频的人来说，命令行虽然第一眼不友好，但一旦用熟，效率碾压GUI工具。

2.2 安装FFmpeg并确认滤镜支持

FFmpeg的安装方式各平台不太一样，但都很快。Windows建议用官方编译版或者通过包管理器，比如winget install FFmpeg，macOS可以用brew install ffmpeg，Linux发行版一般直接apt install ffmpeg或dnf install ffmpeg。装完先验证一下版本：

ffmpeg -version | head -n 3

接着确认你的FFmpeg编译了zscale滤镜和tonemap滤镜。这两个是做色彩空间转换和色调映射的核心，如果版本很旧可能缺少它们。检查命令：

ffmpeg -filters | grep zscale ffmpeg -filters | grep tonemap

只要能看到输出，说明滤镜是齐全的。我见过不少老教程还在用scale滤镜做分辨率缩放和format滤镜转色彩空间，但真正处理BT.2020到BT.709这种跨色域转换，zscale才是正确工具，因为它支持传递色彩信息，能避免颜色偏移。

2.3 核心参数扫盲：zscale、tonemap、colorspace、format

FFmpeg的滤镜不少，但HDR转SDR主要就靠四个滤镜：zscale、tonemap、colorspace、format。逐个说。

zscale是高质量缩放滤镜，比scale多了一堆色彩管理参数。比如zscale=t=linear:npl=100会把色彩空间转换到线性光，并以100尼特为参考。配合matrix=bt709:primaries=bt709:transfer=bt709可以把BT.2020的内容映射到BT.709坐标。

tonemap是真正的色调映射滤镜，它的作用是把HDR的高动态范围亮度压缩到SDR范围。常用参数有tonemap=bt2390、tonemap=hable、tonemap=mobius等，后面的值代表不同的映射函数。简单理解，它决定画面里的高光从亮到暗是“柔和滚动”还是“硬切”。

colorspace滤镜配置色彩空间转换的元数据，保证输出文件的色彩标记正确。转换过程中如果只改像素不改元数据，播放器还是会按错误的色彩空间解码。

format滤镜用来指定像素格式，比如format=yuv420p是8位4:2:0，兼容性最好。HDR源通常是10位的yuv420p10le，不转成8位yuv420p，很多播放器可能不认。

这四个滤镜经常串在一起用，顺序很重要，稍后会专门讲。你把它们当成流水线上的四道工序：先拆解、再压缩、再重新打包、最后贴标签。

2.4 理解滤镜链的执行顺序

滤镜链的执行顺序直接决定最终画面的颜色是否准确。以最常见的转SDR流程为例，正确顺序一般是：

1. 解码源文件，得到带色彩元数据的BT.2020 PQ视频帧。
2. 用zscale把画面转到线性空间，并指定npl（名义峰值亮度）。
3. 用tonemap做亮度压缩，高光部分压进目标范围。
4. 用zscale把线性空间转回目标SDR色彩空间，通常是BT.709。
5. 用colorspace设置输出文件的色彩元数据为BT.709。
6. 用format把像素格式转成yuv420p，保证兼容。

反过来，如果先转像素格式再做色调映射，会导致计算精度不够，颜色断层明显。如果漏掉colorspace，输出文件的元数据还是BT.2020，播放器会再次“误判”，画面又回到发灰状态。所以每次调整命令时，都要顺着滤镜链的顺序检查一遍，不要跳步。

3. 可直接复用的HDR转SDR命令合集

3.1 新手首选：一条默认参数命令

如果你不想研究太多参数，只想把一部HDR视频转成能看的SDR，直接用下面这条。它以HDR10（PQ曲线）源为基准，自动完成色彩空间转换和色调映射：

ffmpeg -i input.mkv -map 0:v:0 -map 0:a:0 -c:v libx264 \ -vf "zscale=t=linear:npl=100,tonemap=bt2390:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p" \ -c:a aac -b:a 192k -crf 18 -preset slow output.mp4

逐段解读一下。zscale=t=linear:npl=100先把视频转到线性光，同时告诉滤镜“源片的名义峰值亮度是100尼特”吗？不是，npl的值是目标参考亮度，一般SDR按100处理，你也可以根据片源调整，比如100就是常规值。tonemap=bt2390:desat=0采用BT.2390标准的映射曲线，这个算法对高光滚动处理比较自然，颜色不会过分变暗，desat=0表示不额外降低高光饱和度。后面一段zscale=t=bt709:m=bt709:r=tv把线性光转回BT.709，像素范围限制在tv（有限范围），再通过format=yuv420p保证兼容性。

路径、编码都按常规做了，crf 18是高画质档，如果希望文件小一点可以调到20到22。音频直接复制也不会有问题，命令里的aac适合网络分发。我建议新手先用这条默认命令在短片上测试，确认输出画面正常后，再去调整其他参数。

3.2 进阶：手动指定色域和亮度

自动命令省事，但有时候源片亮度很高，比如4000尼特内容，npl保持100会导致高光压缩太狠，画面整体偏暗。这时候可以手动指定参数，把色调映射做得更精细。

先看一个更完整的命令：

ffmpeg -i input.mkv -map 0:v:0 -c:v libx265 -crf 20 -preset medium \ -vf "setparams=color_primaries=bt2020:color_trc=smpte2084:colorspace=bt2020nc,zscale=t=linear:npl=1000,tonemap=bt2390:desat=2,zscale=t=bt709:m=bt709:r=tv,colorspace=bt709:iall=bt2020:all=bt709,format=yuv420p" \ -tag:v hvc1 output.mp4

setparams是确保解码后的帧带上正确的色彩参数。有些源的元数据缺失或不标准，加上这一步能强制指定BT.2020和PQ转移函数，避免后续滤镜读错。zscale=t=linear:npl=1000则把源片峰值定为1000尼特，这一步会影响色调映射的起点，如果你的源片是1000尼特内容，这个值更合理。tonemap=bt2390:desat=2是给饱和度过高的高光区域降低一点饱和度，数值2表示降低程度，可以试1到3之间的值。

编码这里用了libx265加-tag:v hvc1，输出HEVC格式，苹果设备兼容性更好。如果你的播放器更喜欢H.264，把-c:v libx265换成libx264就行，但H.264压缩HDR转换后的SDR高码率文件体积会大不少。

3.3 批量处理多个文件的脚本思路

单条命令会写了，批量处理只是加一层循环。Linux或macOS下可以写一个简单的shell脚本：

#!/bin/bash for input in ./*.mkv; do output="${input%.*}_SDR.mp4" ffmpeg -y -i "$input" -map 0:v:0 -map 0:a:0 -c:v libx264 -crf 20 \ -vf "zscale=t=linear:npl=1000,tonemap=hable,zscale=t=bt709:m=bt709:r=tv,format=yuv420p" \ -c:a aac -b:a 192k "$output" done

Windows PowerShell下可以这样：

Get-ChildItem *.mkv | ForEach-Object { $output = $_.BaseName + "_SDR.mp4" ffmpeg -y -i $_.Name -map 0:v:0 -map 0:a:0 -c:v libx264 -crf 20 ` -vf "zscale=t=linear:npl=1000,tonemap=hable,zscale=t=bt709:m=bt709:r=tv,format=yuv420p" ` -c:a aac -b:a 192k $output }

需要注意变量引号，PowerShell里的反引号不是shell注释，是续行符。批量跑之前一定先拿一个文件测参数，确定没问题再全量执行，否则压了十个小时发现方向错了，想死的心都有。

4. 参数细节与画质调优

4.1 tonemap算法对比：bt2390、hable、mobius、clip

tonemap滤镜支持多种映射函数，我用下来不同算法的差异可以用一句话概括：clip最暴力，hable最“讨喜”，mobius偏保守，bt2390相对均衡。

我自己的默认选择是bt2390，它在大多数源片上不会出现奇怪的色偏。如果你发现转出来的画面高光过亮或者暗部太黑，可以切换成hable试试。有人会觉得hable对比度太强，那再换成mobius。每种算法我都建议拿同一个片段多对比几次，眼睛收货比参数表准确得多。

4.2 色彩空间转换顺序为什么不能乱

很多人第一次自己拼命令时，习惯简单堆滤镜，结果发现颜色怎么调都不对。其实色彩空间转换是有严格的顺序逻辑的，核心原则是：亮度压缩必须在线性空间里完成，色彩空间转换必须在非线性空间里通过色彩矩阵完成，两者不能颠倒。

具体到滤镜链：

zscale=t=linear:npl=1000 tonemap=... zscale=t=bt709:m=bt709:r=tv

先用zscale把PQ的非线性编码转成线性光，tonemap才能准确操作亮度值。如果在非线性空间直接压高光，相当于把关键点映射到错误位置，画面很容易丢失层次。再将线性光转回BT.709时，还要通过矩阵变换把RGB原色坐标从BT.2020换成BT.709，这一步由zscale=m=bt709完成。如果漏掉matrix参数，色彩虽然压了，但原色坐标没换，绿色和红色就会明显错位。

一个常见的错误是漏掉最后的colorspace滤镜。有些命令只做了像素转换，没有重写元数据，结果播放器看到文件里的color_primaries还是bt2020，强制用BT.2020解码，画面又是灰的。正确的做法是转换完像素后，通过colorspace滤镜同步设置输出文件的色彩参数，把三个标签都改为bt709和smpte170m或bt709。

4.3 输出编码与色深的选择

转成SDR之后，输出8bit还是10bit是一个需要权衡的问题。大多数SSDR播放器和在线平台都接受8bit的yuv420p，文件体积更小，兼容性最好。但如果你的片源是10bit HDR，转成8bit SDR有可能在渐变天空、肤色过渡区出现色带，尤其码率不够时更明显。

折中方案是用10bit编码输出SDR，也就是format=yuv420p10le，同时编码器换成libx265，配合较慢的preset，能在不大幅增加体积的前提下缓解色带。代价是部分老的播放器可能不支持10bit，所以如果分发目标平台不明确，我建议先出8bit版本，再根据反馈决定要不要出10bit精修版。

编码器方面，libx264快、兼容性好，但处理高动态范围画面的色带控制不如libx265，尤其低码率下。我个人经验是，如果文件要上传网络平台，优先libx264，crf控制在18到20；如果本地收藏，用libx265加crf 18到20更香。

5. 实战案例：完整压制一部HDR电影为SDR MP4

5.1 视频、音频、字幕一起处理

前面讲的是纯视频转换，实际压片通常还要处理音频和字幕。拿一部典型的HDR电影举例，假设文件是movie.mkv，包含一条HDR10视频流、一条DTS-HD MA音频、一条PGS字幕。转换成适合播放器直接放的SDR MP4，我通常分两步。

第一步，先抽取字幕。PGS字幕是图像格式，MP4容器兼容性一般，我习惯先用ffmpeg -i movie.mkv -map 0:s:0 subs.srt看能不能提取到文本字幕，提不到就保持外挂PGS也没关系，但MP4内嵌PGS在不少电视上会出问题。

第二步，压视频并把音频转成AAC。一条完整命令：

ffmpeg -y -i movie.mkv -map 0:v:0 -map 0:a:0 \ -vf "setparams=color_primaries=bt2020:color_trc=smpte2084:colorspace=bt2020nc,zscale=t=linear:npl=1000,tonemap=bt2390:desat=2,zscale=t=bt709:m=bt709:r=tv,colorspace=bt709:iall=bt2020:all=bt709,format=yuv420p" \ -c:v libx264 -crf 19 -preset slow \ -c:a aac -b:a 192k -ac 2 \ -movflags +faststart -sn movie_SDR.mp4

-movflags +faststart让MP4文件的元数据放到文件头，在线播放时能快速启动播放，这个参数我压片必加。-sn是去掉字幕流，避免容器兼容问题。如果想把字幕烧进画面，把命令里加一个-vf链合并subtitles=movie.srt即可，注意烧录字幕会引入额外文字渲染，建议单独处理。

5.2 操作前后画质对比与验证

压完之后不要直接交片，先做验证。最直接的方式是拿播放器放几段，重点看三处：开头高光天空有没有死白、人物肤色是否自然、暗部是否还有层次。如果你想量化，可以用FFmpeg自带信号统计滤镜：

ffprobe -v error -select_streams v:0 -show_entries stream=color_space,color_transfer,color_primaries,width,height,pix_fmt -of default=noprint_wrappers=1 movie_SDR.mp4

如果输出的color_space是bt709，color_transfer是bt709（或smpte170m），pix_fmt是yuv420p，说明色彩元数据正确。否则检查滤镜链是否漏了colorspace。再看不放心的，可以截取几帧对比：

ffmpeg -i movie_SDR.mp4 -vf "select='eq(n\,300)'" -vframes 1 frame300.png

把源片和输出片同时截同一帧，放进看图软件对比。SDR版本高光应该比HDR源压暗，但整体曝光不能偏灰，肤色不能发紫，这就是合格状态。

5.3 性能优化与硬件加速

HDR转SDR整个过程计算量不小，尤其tonemap和zscale滤镜都是浮点运算，CPU软解转码一部90分钟电影可能要好几个小时。急着出片的话，可以试试硬件加速。

FFmpeg对常用显卡有支持，NVENC编码器通过-c:v h264_nvenc或hevc_nvenc调用，前提是编译版本带对应模块。滤镜链中的zscale和tonemap依然是CPU计算，但编码部分能显著提速。命令长这样：

ffmpeg -i input.mkv -map 0:v:0 -vf "zscale=t=linear:npl=1000,tonemap=bt2390,zscale=t=bt709:m=bt709:r=tv,format=nv12" \ -c:v h264_nvenc -preset p5 -cq 19 -c:a copy output.mp4

注意硬件编码对像素格式有要求，NVIDIA编码器通常用nv12而不是yuv420p，所以格式改成format=nv12。-cq是NVIDIA的码率控制参数，类似crf，数值越小画质越好。实际压片时，如果只是预览，用硬件编码能省很多时间；如果追求最终交付画质，还是老老实实用libx264或libx265加slow预设。

6. 常见问题排查与避坑手册

6.1 转换后颜色发灰、发紫

发灰和发紫是HDR转SDR最高频的翻车现场。发灰主要是因为输出文件的色彩元数据还是BT.2020/PQ，播放器按错误的曲线解码。排查方法是先跑一遍ffprobe看元数据，如果没变，就在滤镜链最后补上colorspace=bt709:iall=bt2020:all=bt709。

发紫则多半是矩阵转换出错，也就是zscale=m=bt709没设对，或者源片本身是Dolby Vision，而你的FFmpeg没有正确处理其增强层。Dolby Vision片源建议先通过工具提取出基础的HDR10层，再做转换，否则颜色通常偏紫红。遇到这类源片，直接用ffmpeg -f lavfi -i color=black...之类的测试没有意义，先把源处理好再转。

6.2 高光过曝或画面偏暗

如果转出来的画面高光一片惨白，多半是npl值设置过低，色调映射没来得及压缩高光，直接裁掉了。把npl调高，比如从100改成400或1000，让映射曲线知道源片峰值亮度有多高，高光细节就保住了。

反过来画面整体偏暗，可能是npl设置过高，映射起点太高导致中灰被压暗。这时把npl调低，或者换用tonemap=hable试试。不要盲目改颜色亮度，先调整映射参数，大多数曝光问题都能解决。

6.3 滤镜执行报错

执行转换时最常见的报错是No such filter或Filter tonemap not found。这通常是因为FFmpeg编译版本太老，缺少滤镜。解决方法不是绕开，而是换一个带完整滤镜支持的FFmpeg构建版，比如官网的release build或者BtbN的构建，基本都包含zscale和tonemap。

另一个常见报错是Invalid npl value，多半是npl参数写成了浮点数之外的格式，或者缺少等号。滤镜参数里一定不要乱加空格，zscale=t=linear:npl=100和zscale=t=linear : npl=100是两回事，后者会报错。

6.4 压片效率太低怎么办

如果确认滤镜链和参数都没有问题，就是压得慢，先检查是不是用了软编码加slow预设，同时滤镜计算占用了大量CPU。你可以用-threads 0让FFmpeg自动使用全部核心，或者适当调高crf值、换成preset faster。还有一招是先把视频降低噪声预处理，比如-vf "hqdn3d=1.5:1.5:6:6"，但不要过度，不然画面会变软。

根据我个人经验，硬解滤镜还没有完全可靠，硬件加速更多用在编码端。想兼顾速度和画质，推荐工作流是先用CPU滤镜出一次代理，确认参数没问题后再用硬件编码或高并发跑最终版本，这样既省心又不浪费电。

最后分享一个小习惯，我会把同一段源片用不同参数转出四五个版本，放同一个播放器里逐帧对比。看起来麻烦，其实比盯着参数表猜效率高得多。FFmpeg的命令再多，最后还是要回归到“输出画面是否符合你的播放场景”这个唯一标准上。你手里那片HDR素材到底适合哪条命令，跑几轮对比自然就有答案了。