Ffmpeg H.264至DNxHR 444问题。颜色未正确转码（HDR项目）。注：问题尚未解决

我在使用FFmpeg将mxf容器中的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文件没有。所以这不是首映式的出口问题，而是和原始转码有关的问题

我知道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_layou layout 63-map 0:2-隐藏旗帜输出.mxf

就像我说的，在转码之后，两个视频文件在颜色方面看起来都有很大的不同。在Premiere中使用它们并以完全相同的设置导出后，输出文件也会出现相同的差异

Mediainfo显示两个文件的预期数据： -原始h.264文件的10位，主10，5级，4:2:0，CBR，BT.2020。 -10位，4:4:4，DNxHR 444文件的CBR

我在Mediainfo中注意到的一点是，两者都有YUV作为颜色空间，但DNxHR 444视频有一个额外的字段，上面写着ColorSpace_Original:RGB。老实说，我不知道那是什么意思，因为原作是YUV。颜色范围很好，从0到1023（以及色度范围1023）。另一件事是它在H.264文件的颜色范围字段上显示“limited”，但我读到这可能是Mediainfo对文件的错误或错误解释

好了，就这样，任何帮助都将不胜感激。我真的很想用DNxHR 444作为源文件进行编辑，用DNxHR LB作为代理进行编辑，这样我就可以快速编辑，而且不会出现同步问题，但是颜色是不可接受的。我知道我正在添加一个额外的代码转换步骤（从原始到DNxHR），但是原始和DNxHR代理之间的同步问题，即使可能是一个几分之一秒的延迟，也会使我的工作流程变得更加困难，因为我将不得不多次导出，以查看是否在我希望的位置进行了剪切。无论如何都不理想。而Prores显然不是一个选项，同步问题要严重得多。对我来说，这一切都归结为能够得到一个DNxHR 444文件，看起来，嗯，尽可能接近无损，这一目标显然涉及到颜色

提前谢谢

PS：文件大小对我来说不是问题，所以将整个UHD HDR电影转码到DNxHR 444不是问题

PS2：我尝试了不同的色度子采样（如DNxHR HQX 10位，即4:2:2），结果相同。我还没有尝试使用8位，但我看不出有什么意义，因为这是一个HDR项目

更新：

我尝试在MXF容器中使用Adobe Media Encoder而不是FFmpeg将H.264源文件转码为DNxHR视频文件，但颜色没有再次正确转码，但这一次它们似乎过度饱和而不是褪色。AdobeMediaEncoder并没有提供太多的调整空间，但我确保选择444 10位配置文件、相同分辨率（UHD）、相同帧速率以及具有最大质量和最大位深度的渲染。结果文件的FFprobe输出再次将BT709显示为颜色空间（使用FFmpeg转码后，输出文件也会发生同样的情况）。显然，这似乎与FFmpeg无关。有什么想法吗？就好像我无法从H.264到DNxHR正确地进行代码转换和保留颜色，即使使用它最优质的风格和正确的命令设置（至少在我看来它们还可以）。我如何发布这篇文章，这样也许开发者或有丰富经验的人可以给我们一个线索来了解正在发生的事情？谢谢

PS：下面的评论中有更多潜在有用的信息

额外信息：

1）MXF DNxH的FFprobe输出

  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

    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