1

我在使用 FFmpeg 将 H.264 UHD HDR 文件转码为 mxf 容器中的 DNxHR 文件时遇到问题。问题是这两个文件看起来根本不一样，DNxHR 视频上的颜色看起来很褪色，我试图使转码尽可能无损（DNxHR 444 风格）。原始文件是我不久前翻录的电影，H.264、UHD、HDR，在 mkv 容器中。

我的目标：创建一个几乎无损的 DNxHR 文件，将其用作 Adob​​e Premiere Pro 中的源文件，并使用另一个质量较低的 DNxHR 文件作为编辑代理。我想这样做，而不是使用原始 H.264 作为源文件，因为它与代理文件不同步（我的意思是，当我打开和关闭代理图标时，你可以看出有一个短暂的延迟它们之间，这破坏了所有的编辑目的）。我的猜测是，这可能是因为 H.264 已压缩而 DNxHR 未压缩，并且由于我进行了很多快速剪辑，因此我需要尽可能同步源文件和代理文件。当源文件和代理文件都是 DNxHR 时，无论哪种风格，它们都完美同步。我不想和 Prores 一起去代理，

嗯，问题是当我将原始 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 显示两个文件的预期数据： - 10 位，主要 10，级别 5，4:2:0，CBR，BT.2020 原始 h.264 文件。- 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 项目。

更新：

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

PS：有关以下评论的更多潜在有用信息。

额外信息：

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 bits, 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
4

1 回答 1

1

如果您可以将输出发布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。同步的问题在于帧间，帧内很好，所以只使用帧内（-g 0或-intra）。

于 2020-01-20T14:23:35.423 回答