我在使用FFmpeg将m.f容器中的H.264 UHD HDR文件转码为DNxHR文件时遇到问题。问题是两个文件看起来根本不一样，DNxHR视频上的颜色看起来褪色了，我尝试使转码尽可能无损（DNxHR 444风格）。原始文件是我前一段时间在mkv容器中翻录的电影H.264，UHD，HDR。
我的目标：创建一个几乎无损的DNxHR文件，以将其用作Adobe Premiere Pro中的源文件，并使用另一个质量较低的DNxHR文件作为代理进行编辑。我想这样做，而不要使用原始的H.264作为源文件，因为它与代理文件不同步（我的意思是，当我打开和关闭代理图标时，您可以知道会有短暂的延迟在它们之间，这会破坏所有用于编辑的目的。我的猜测是，可能是因为H.264被压缩而DNxHR没有被压缩，并且由于我进行了很多快速剪辑，所以我需要源文件和代理文件都尽可能地同步。当源文件和代理文件均为DNxHR时，无论使用哪种样式，都可以完美同步。我不想使用Prores作为代理，因为同步问题更加严重（文件之间延迟几秒钟），可能是因为它是VBR编解码器，而我的原始文件和DNxHR是CBR（出于记录目的，我总是更喜欢CBR）。
好吧，当我将原始H.264文件导入Premiere Pro时，请使用DNxHR代理，进行一些编辑，然后直接从原始文件中导出（H.264 10位，需要所有设置如果启用了HDR输出），则颜色应如其应。当我对高质量的DNxHR作为源文件执行相同的操作时，使用完全相同的导出设置，颜色看上去就变淡了。与任何DNxHR口味相同。
然后，我用VLC打开了两个文件（原始的H.264和从H.264编码的高质量DNxHR编码文件），而且我还可以告诉mxf文件看起来已被冲洗掉，而H.264文件却没有。因此，这不是Premiere方面的出口问题，这与原始代码转换有关。
我知道DNxHR 444可以像使用该编解码器一样无损，保留了所有HDR所需的数据，并且我相信mfx容器比MOV更具优势，MOV是另一个支持DNxHD / DNxHR的容器。所以我不知道到底发生了什么。
我使用的命令是：
ffmpeg -channel_layout 63 -i input.mkv -map 0:0 -c:v dnxhd -vf "scale=in_range=limited:out_range=full" -color_range 2 -profile:v dnxhr_444 -pix_fmt yuv444p10le -acodec pcm_s24le -ar 48000 -ac 6 -channel_layout 63 -map 0:2 -hide_banner output.mxf
[就像我说过的那样，在转码后，两个视频文件在颜色方面看起来彼此都很大不同。在Premiere中使用它们并以完全相同的设置导出后，输出文件会有相同的差异。
Mediainfo显示两个文件的预期数据：-原始h.264文件的10位，主10位，5级，4：2：0，CBR，BT.2020。-DNxHR 444文件为10位，4：4：4，CBR。
我在Mediainfo中注意到的一件事是，两者都具有YUV作为色彩空间，但是DNxHR 444视频有一个额外的字段，表示ColorSpace_Original：RGB。老实说，我不知道这意味着什么，因为原来是YUV。颜色范围从0到1023（以及色度范围1023）很好。另一件事是，它在H.264文件的颜色范围字段上说“受限”，但是我读到那可能是Mediainfo对文件的错误或错误解释。
就是这样，任何帮助将不胜感激。我真的很想使用DNxHR 444作为源文件进行编辑，而使用DNxHR LB作为代理进行编辑，因此我可以快速进行编辑并且没有同步问题，但是颜色是不可接受的。而且我确实知道我要添加一个额外的转码步骤（从原始代码到DNxHR），但是原始代码和DNxHR代理之间的同步问题（即使可能会延迟一秒钟），使我的工作流程变得更加困难。难度要大得多，因为我必须多次导出才能查看切割是否精确到我希望的位置。无论如何都不理想。而且Prores显然不是一个选择，同步问题要严重得多。对我而言，一切都取决于能够获得看起来几乎无损的DNxHR 444文件，并且该目标显然涉及颜色。
提前感谢。
PS：文件大小对我来说不是问题，因此将整个UHD HDR电影转码为DNxHR 444并不是问题。
PS2：我尝试了不同的色度二次采样（例如DNxHR HQX 10位，即4：2：2），结果相同。尚未尝试使用8位，但是我看不出重点，因为这是HDR项目。
额外信息：
1] MXF DNxHR文件的FFprobe输出（此为4：2：2，与在OP上声明的命令相比，所用命令的唯一区别是-pix_fmt yuv444p10le为-pix_fmt yuv422p10le）：
libavutil 56. 31.100 / 56. 31.100
libavcodec 58. 54.100 / 58. 54.100
libavformat 58. 29.100 / 58. 29.100
libavdevice 58. 8.100 / 58. 8.100
libavfilter 7. 57.100 / 7. 57.100
libswscale 5. 5.100 / 5. 5.100
libswresample 3. 5.100 / 3. 5.100
libpostproc 55. 5.100 / 55. 5.100
[mxf @ 000001f4d17fbac0] Stream #0: not enough frames to estimate rate; consider increasing probesize
Input #0, mxf, from 'Interstellar_Master_DNxHR_444_UHD_422_PCM24_5.1.mxf':
Metadata:
operational_pattern_ul: 060e2b34.04010101.0d010201.01010900
uid : adab4424-2f25-4dc7-92ff-29bd000c0000
generation_uid : adab4424-2f25-4dc7-92ff-29bd000c0001
company_name : FFmpeg
product_name : OP1a Muxer
product_version : 58.29.100
product_uid : adab4424-2f25-4dc7-92ff-29bd000c0002
material_package_umid: 0x060A2B340101010501010D001393EE79529471348D93EE7900529471348D9300
timecode : 00:00:00:00
Duration: 02:49:03.97, start: 0.000000, bitrate: 1404833 kb/s
Stream #0:0: Video: dnxhd (DNXHR 444), yuv444p10le(bt709/unknown/unknown, progressive), 3840x2160, SAR 1:1 DAR 16:9, 23.98 tbr, 23.98 tbn, 23.98 tbc
Metadata:
file_package_umid: 0x060A2B340101010501010D001393EE79529471348D93EE7900529471348D9301
Stream #0:1: Audio: pcm_s24le, 48000 Hz, 6 channels, s32 (24 bit), 6912 kb/s
Metadata:
file_package_umid: 0x060A2B340101010501010D001393EE79529471348D93EE7900529471348D9301
2） MP4 H.264源文件的FFprobe输出（此为4：2：0、10位，HDR）：
Stream #0:0(eng): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 15584 kb/s, 23.98 fps, 23.98 tbr, 16k tbn, 23.98 tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(eng): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, 5.1(side), fltp, 640 kb/s (default)
Metadata:
handler_name : SoundHandler
Side data:
audio service type: main
Stream #0:2(eng): Data: bin_data (text / 0x74786574)
Metadata:
handler_name : SubtitleHandler
Unsupported codec with id 100359 for input stream 2
如果您可以将ffprobe的输出发布到H264文件上，这会有所帮助吗？可能有一些原因造成了这种情况，我们可以通过查看输入文件的类型来找出其中的大部分。
H.264可能是4：2：0，而您将上采样到4：4：4（-pix_fmt yuv444p10le）或4：2：2（“ PS2”）。出于所有实际目的和目的，转换对于质量从来都不是一件好事，因此，如果文件为4：2：0，则永远将数据保留在4：2：0中。您将不会获得信息，但是转换将导致进一步的质量损失。从有限范围到全范围（scale=in_range=limited:out_range=full）的转换也是如此。
由于DNXHD实际上并不支持4：2：0，因此您有各种选择。一种简单的方法是使用仅内部H.264。同步的问题在于帧间，intra很好，因此只能使用intra（-g 0或-intra）。