У меня проблема с перекодировкой HDR-файла H.264 UHD в файл DNxHR в контейнере mxf с помощью FFmpeg. Проблема в том, что оба файла не выглядят одинаково, цвета выглядят размытыми на видео DNxHR, и я попытался сделать транскодирование максимально без потерь (вариант DNxHR 444). Оригинальный файл - mov ie. Я скопировал некоторое время go, H.264, UHD, HDR, в контейнер mkv.
Моя цель: создать файл DNxHR с почти без потерь, чтобы использовать его в качестве исходного файла в Adobe Premiere Pro и использовать другой файл DNxHR с меньшим качеством в качестве прокси для редактирования. Я хотел сделать это таким образом, а не использовать исходный H.264 в качестве исходного файла, потому что он не синхронизирован c с файлом прокси (я имею в виду, когда я включаю и выключаю значок прокси, вы можете сказать, что есть небольшая задержка между ними, которая побеждает все цели для редактирования). Я предполагаю, что это может быть из-за того, что H.264 сжат, а DNxHR нет, и, поскольку я редактирую много быстрых сокращений, мне нужно, чтобы исходный файл и файл прокси были синхронизированы как можно быстрее. Когда исходный файл и прокси-файл имеют DNxHR, независимо от их вкуса, они идеально синхронизируются. Я не хочу go с Prores для прокси, потому что проблема syn c намного хуже (несколько секунд задержки между файлами), возможно, потому что это код VBR c и мой исходный файл и DNxHR являются CBR (для записи, я всегда предпочитаю CBR).
Ну, дело в том, что когда я импортирую оригинальный файл H.264 в Premiere Pro, использую прокси DNxHR, немного редактирую и экспортирую его непосредственно из исходного файла (10 бит H.264, со всеми необходимыми настройками для вывода HDR) цвета выглядят так, как должны. Когда я делаю то же самое с высококачественным DNxHR в качестве исходного файла с точно такими же настройками экспорта, цвета выглядят размытыми. То же самое с любым ароматом DNxHR.
Затем я открыл оба файла (исходный H.264 и высококачественный DNxHR, перекодированный из H.264) с помощью VL C, и я также могу сказать, что файл mxf выглядит размытым, а файл H.264 нет. Так что это не проблема экспорта на стороне Premiere, это то, что связано с оригинальным транскодированием.
Я понимаю, что DNxHR 444 настолько же без потерь, насколько вы можете получить с этим кодом c, сохраняя все HDR требовал данных, и я считаю, что у контейнера mfx есть некоторые преимущества перед 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. - 10 бит, 4: 4: 4, CBR для файла DNxHR 444.
Одна вещь, которую я заметил в Mediainfo, состоит в том, что оба имеют YUV в качестве цветового пространства, но видео DNxHR 444 имеет дополнительное поле, которое говорит ColorSpace_Original : RGB. Честно говоря, я не знаю, что это значит, так как оригинал - YUV. Цветовая гамма в порядке, от 0 до 1023 (и цветность 1023). Другое дело, что в поле цветового диапазона файла H.264 написано «ограничено», но я читал, что это может быть ошибкой или неправильной интерпретацией файла Mediainfo.
Ну, это это, любая помощь будет оценена. Я действительно хотел бы редактировать с DNxHR 444 в качестве исходного файла и DNxHR LB для прокси, чтобы я мог редактировать в быстром темпе и без проблем с syn c, но цвет просто не приемлем. И я понимаю, что я добавляю дополнительный шаг транскодирования (от оригинала к DNxHR), но проблема syn c между оригиналом и прокси DNxHR, даже если это может быть задержка доли секунды, делает мой рабочий процесс намного сложнее, так как мне придется многократно экспортировать, чтобы увидеть, сделаны ли сокращения именно там, где я хочу, чтобы они были. Не идеал ни в коем случае. И Prores не вариант, по-видимому, проблема syn c гораздо хуже. Для меня все сводится к возможности получить файл DNxHR 444, который выглядит, ну, как можно ближе к без потерь, и эта цель, очевидно, включает в себя цвета.
Заранее спасибо.
PS: размер файла не является для меня проблемой, поэтому не нужно создавать перекодированный в DNxHR 444 целый HDR mov ie.
PS2: я пробовал с другой подвыборкой цветности ( как DNxHR HQX 10 битов, что составляет 4: 2: 2), тот же результат. Еще не пробовал с 8 битами, но я не вижу смысла, так как это проект HDR.
ОБНОВЛЕНИЕ:
Я пытался транскодировать с Исходный файл H.264 для видеофайла DNxHR в контейнере MXF с использованием Adobe Media Encoder вместо FFmpeg, и цвета снова не транскодируются правильно, но на этот раз они кажутся перенасыщенными, а не размытыми. Adobe Media Encoder не оставляет много места для настройки, но я выбрал 444 10-битный профиль, такое же разрешение (UHD), одинаковую частоту кадров и рендеринг с максимальным качеством и максимальной битовой глубиной. Вывод FFprobe полученного файла снова показывает BT709 в качестве цветового пространства (то же самое происходит с выходным файлом после транскодирования с использованием FFmpeg). Кажется, что-то не связанное с FFmpeg. Любые идеи? Как будто нет никакого способа, которым я могу перекодировать и сохранять цвета правильно от H.264 до DNxHR, даже используя его самый высококачественный аромат и правильные настройки команд (по крайней мере, они выглядят хорошо для меня). Как я могу опубликовать это, чтобы разработчики или люди с большим опытом здесь могли дать нам подсказку о том, что происходит? Спасибо.
PS: Более потенциально полезная информация в комментариях ниже.
ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ:
1) FFprobe output файла MXF DNxHR (это 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) Вывод FFprobe исходного файла MP4 H.264 (это 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