Кодирование видео из пакета DCP (Формат видеоконтента в кинотеатрах на цифровых проекторах) 10/12 бит в Hi10P

У меня есть доступ к трейлерам фильмов в dcp. Я их выкладываю в раздел "Трейлеры и дополнительные материалы к фильмам" сохраняя оригинальное разрешение видео и оставляя без изменений аудиодорожку.
Все видео=исходники имеют битовую глубину 12 бит,реже 10 бит,я же кодирую их x264 в 8 бит.
Нужна помощь с реализацией перекодирования в Hi10P через батник. И нужно ли это,или достаточно 8 бит?
Способ кодирования dcp-avc от alexxdls через ffmpeg : http://yadi.sk/d/UAhvPYYoHuEUY

Около года назад я также заинтересовался созданием 10-битных рипов с DCP.
Ниже я расскажу, какие у меня проблемы были с созданием 10-битных рипов, и как я их все в итоге разрешил.
А в самом конце этого сообщения вы найдёте мой конвертер "DCP HQ rip maker", предназначенный для создания высококачественных рипов с DCP, и который является результатом всех моих исследований, наблюдений и наработок по созданию рипов с DCP, описанных в этом сообщении. Под высококачественным рипом с DCP понимается 10-битное видео с субдискретизацией насыщенности 4:4:4 и полным цветовым диапазоном.

---

Изначально интерес был вызван появлением в интернете DCP-рипа тизер-трейлера "Как приручить дракона 2" в вертикальной анаморфной стереопаре. На тот момент я уже знал, что такое DCP, что у него глубина цвета 12 бит на канал с субдискретизацией насыщенности 4:4:4, и я даже как-то пробовал разбирать какой-то DCP при помощи "OCT", который я когда-то скачал где-то отсюда: http://cinemaprofs.ru/viewtopic.php?f=7&t=2. И мне захотелось достать этот самый DCP тизер-трейлера "Как приручить дракона 2", потому что я просто хотел посмотреть в нём на картинку, заценить 12-битную глубину цвета и поиграться с уровнями в Photoshop'е. :3 А также очень хотелось послушать 5.1 lossless звук в дубляже, там в тизер-трейлере играет шикарная композиция от Audiomachine.
Связавшись с автором того самого рипа тизер-трейлера в вертикальной анаморфной стереопаре, мне удалось достать сперва 3D DCP тизер-трейлера, а потом и 2D DCP. После извлечения кадров из DCP и преобразования их в TIFF с помощью OCT, я начал их рассматривать и изучать. А потом мне стало интересно, а что если попробовать создать 10-битный рип в качестве эксперимента? До этого я уже встречал в интернете 10-битные рипы аниме, а также 10-битный рип мультфильма Синтел в 4K, выглядели они здорово. Но мне не понравился способ, которым было закодировано 10-битное видео Синтел - для кодирования 10-битного видео там использовался AviSynth, но поскольку AviSynth поддерживает максимум 8 бит на канал, то автор рипа использовал обход, суть которого в предварительном разделении через ImageMagick верхних 8 бит и нижних 8 бит картинки, создавая таким образом 8-битные кадры с двое большим разрешением по вертикали, где были таким образом записаны все биты. Я решил попробовать поискать в интернете, есть ли какие-нибудь способы закодировать настоящие 10-бит напрямую с последовательности кадров.
И в результате поисков я наткнулся на вот эту тему: http://forums.akross.ru/cgi-bin/ikonboard.cgi?act=ST;f=2;t=6841 Где было написано про некий VapourSynth, который, согласно написанному, поддерживал 16 бит на канал, в отличие от AviSynth, и позволял таким образом закодировать "труЪ" 10 бит. Я решил попробовать сделать с его помощью рип, и начал разбираться.
Для начала написал батник, с помощью которого через ImageMagick сконвертировал все tiff в 16-битные png. Установил Python, VapourSynth с официального сайта (на тот момент на сайте был VapourSynth версии r19) и создал скрипт для VapourSynth, используя пример из темы, попутно разбираясь с языком Python, делая ошибки в коде тут и там. И где-то кажется то ли на этом этапе, то ли на последующих (точно уже не помню) у меня появилась проблема, что VapourSynth отказывался принимать последовательность изображений, выдавая ошибку, что якобы поддерживаются только постоянные пиксельные форматы. Причём с одной последовательностью кадров VapourSynth работал, а с другой выдавал ошибку. Начав изучать последовательность кадров, я обнаружил причину ошибки - как оказалось, ImageMagick полностью чёрные кадры сохранял автоматом с глубиной цвета в 1 бит, а не в 48 бит. После чего я нашёл команду в ImageMagick, позволяющую насильно задавать формат PNG, после чего все кадры стали в 48 бит и эта проблема разрешилась. Так удалось в первый раз полностью закодировать тизер-трейлер. Поскольку 10-битные рипы так или иначе смотрят на компьютере, я решил делать рип именно в полном цветовом диапазоне pc range (0-255), чтобы сохранить как можно больше цветов из 12 битных кадров. Одновременно выяснилось, что ffdshow по умолчанию после установки воспроизводит видео в диапазоне 16-235 (tv range), и на первых порах картинка при воспроизведении выглядела слишком тёмной и контрастной, пока я в настройках ffdshow на вкладке "RGB преобразование" (RGB conversion) не установил автоматический выбор входных уровней (Input levels) (у LAV же всё с этим нормально и ничего менять не нужно в настройках). Тогда отображение видео при воспроизведении через ffdshow стало нормальным.
Но это на первый взгляд. В ходе сравнения получившегося рипа с оригинальными кадрами я обнаружил некое малозаметное искажение цветов в рипе. Как будто бы изображение слегка порозовело. Уж не помню, сколько времени я выяснял, в чём причина этого, но в конце концов, экспериментируя так и сяк, обнаружил, что это искажение цветов происходит при выводе в цветовые пространства Y410 и Y416 (LAV и ffdshow соответственно), при чём это не проблема самого видео, так как в RGB32 цвета отображаются как должны, а проблема некорректной обработки в этих цветовых пространствах видео с полным цветовым диапазоном (PC range). С этого момента я стал воспроизводить 10-битное видео в полном цветовом диапазоне только с установленным выводом в RGB32 в настройках ffdshow.
Дальше я уже начал экспериментировать с настройками кодирования x264 и подбирать наилучшие настройки для кодирования 10-битного 4:4:4 видео, читая разнообразную литературу и советы в интернете, ориентируясь при этом на рип мультфильма Синтел от MaLLIeHbKa. Это я пожалуй пропущу. Скажу только лишь, что кодировать рипы с DCP лучше всего с CRF, тогда обеспечивается постоянное качество картинки на протяжении всего видео.
Свой рип тизер-трейлера "Как приручить дракона 2" в Hi444PP и Hi10P я решил выложить на рутрекер, как первый своего рода рип с DCP в таком формате, и сделал я это в сентябре 2013 года. Позже я в ноябре выложил свой рип тизер-трейлера в полной вертикальной стереопаре с разрешением 2048х1716 и обычным 8-битным 4:2:0 видео, которое я закодировал, используя обычный скрипт AviSynth и MeGUI. Но я ещё не был в курсе о кое-каких недостатках преобразования кадров и настроек кодирования. О них я постепенно начал узнавать сам, после того, как в феврале 2014 появился DCP первого трейлера "Как приручить дракона 2".
Тогда казалось не нужным делать дизеринг с 12 до 10 бит, поскольку само видео и так выглядело классно и я не был уверен, так ли этот дизеринг нужен в случае 10-битного видео... После того, как я выложил рипы этого трейлера с 3D DCP в вертикальной анаморфной и вертикальной полноразмерной стереопарах, которые я сделал с помощью всё того же AviSynth MeGUI (то есть без дизеринга), я решил провести ряд тестов со скриптами VapourSynth касательно дизеринга видео до 8 бит и до 10 бит, и я понял, что дизеринг нужен даже 10-битным видео, пускай отличия и не заметны практически. Таким образом рип нового трейлера в 2D Hi444P Hi10P я уже сделал с дизерингом "Sierra-2-4A error diffusion (Filter Lite)", который по результатам тестов мне понравился больше всего. Кроме того, я также пытался задействовать встроенный в x264 дизеринг, который автоматически включается, если ему подавать на вход видео с глубиной больше 10 бит, но качество работы у него оказалось хуже, нежели чем у Sierra-2-4A error diffusion через VapourSynth.

---

Примерно в это же время я при тщательном сравнений скриншотов из рипа с исходными кадрами в PNG (сравнивал из любопытства и так же с целью оценки качества видео получившегося рипа) обнаружил, что скриншоты из рипа были почему-то на 1-2 пункта светлее, чем оригинальные исходные кадры. То есть, например, вместо R165 G30 B70 было R167 G31 B72. Сперва я подумал, что это быть может как-то виноват рендер MadVR. Или может быть это происходит потому, что видео 10-битное. Или же из-за того, что оно было закодировано в полном цветовом диапазоне. Так или иначе, я хотел добиться полного соответствия видео рипа оригинальным кадрам в плане цветов и яркости, поэтому я начал проводить разнообразные тесты с видео и рендерами. Но причина была ни в рендере, ни в самом видео. Когда я уже начал экспериментировать с настройками ffdshow, через который я снимал скриншоты (поскольку через MPC-HC нельзя делать скриншоты с рендером MadVR), я неожиданно обнаружил, что после включения опции "Дизеринг" на вкладке "RGB преобразование" скриншоты стали получится уже такими, какими должны быть, то есть неосветлёнными. Всё дело в том, что, как я уже говорил, я ориентировался на рип "Синтел" от MaLLIeHbKa. Там у Машеньки к скриншотам есть примечание "Скриншоты сняты через ffdshow r4471 с выводом в RGB32, включенной галкой «High quality YV12 to RGB conversion» и отключенным дитерингом.". Я подумал, что именно таким образом и нужно снимать скриншоты с 10-битного видео - чтобы наверно показать, что плавные градиенты у видео есть благодаря именно 10-битной глубине, а не дизерингу ffdshow. Я и предположить не мог, что эта опция дизеринга может делать видео светлее. И в результате проблема оказалась не в самом видео, а в настройках ffdshow. С этого момента я стал делать скриншоты из 10-битного видео с включённой опцией "Дизеринг" в ffdshow. Соответствие оригиналу превыше всего. Тем более, что я не увидел особой разницы в плавности градиентов между скриншотами, снятыми с включённой опцией дизеринга в ffdshow и без.

---

Позже появились DCP первых 5 минут фильма "Как приручить дракона 2", а также второго трейлера. И примерно в это самое время я обратил внимание на некий странный бандинг на очень тёмных участках видео. Раньше я ему не придавал особого значения, думал, что быть может это так было закодировано видео в самом DCP. Его толком было и не увидеть на обычной кадре на мониторе, только в Photoshop через изменение уровней, или же на моём телевизоре Samsung, который очень хорошо показывает тёмные участки видео (так уж он показывает). Но впервые я заострил своё внимание на этом бандинге после того, как просто ради интереса открыл оригинальный j2c-кадр в Photoshop и с удивлением обнаружил, что там на этих самых тёмных участках нет никакого бандинга и что там есть гораздо больше деталей в них. Тогда я понял, что что-то происходит не так при конвертировании через ImageMagick. Раньше я просто использовал строку для конвертации из j2c в tiff через ImageMagick, какая она была в OCT, выложенном в той теме на форуме cinemaprofs.ru, и я не разбирался, что же именно она делает. И теперь настало время разобраться. После прочтения информации в интернете я понял, что там с помощью команд в этой строке выполняется преобразование кадра из цветовой модели XYZ, которая используется в стандарте DCI, в цветовую модель RGB с точкой белого D65, которая используется в PNG и в нашем h264 видео. Выполняется это преобразование следующим образом:
1. Гамма снижается с 2.6 до 1.0, то есть умножается на 1/2.6, что приблизительно равняется 0.3846153846153846 - это нужно для приведения изображения к линейному RGB.
2. Применяется матрица для преобразования из XYZ в RGB, являющейся обратной матрице из RGB в XYZ. Данную матрицу можно найти в интернете, например, на этом сайте.
3. Гамма восстанавливается до стандартной для RGB 2.2, то есть умножается на 2.2.
Так вот, я решил посмотреть, как же будет выглядеть изображение, если не выполнять полностью преобразование цветовой модели, а только лишь снизить его гамму с 2.6 до 1.0 через тот же самый ImageMagick, что я использовал для конвертации, и что поставлялся вместе с OCT, который я скачал на форуме. Снизив гамму, я открыл получившееся изображение в Photoshop, начал постепенно осветлять картинку, увеличивая уровни (выполняя преобразования 0-2 -> 0-255), и наконец увидел то, что ожидал - те самые артефакты и бандинг на изображении, которые я видел ранее. И я понял, что, оказывается, 16 бит просто недостаточно, чтобы достоверно передать такие тёмные участки. Из-за недостаточной точности расчётов и происходит эта самая потеря информации в тёмных областях. Самые тёмные участки как бы "сплющиваются". Детали потеряны, и потом уже, после применения матрицы и восстановления гаммы до 2.2, эти тёмные участки с потерянными деталями выглядят как артефакты и бандинг.
Одновременно я понял, что для того, чтобы избавиться от этих артефактов, нужно при преобразовании из XYZ в RGB использовать расчёты с точностью как минимум 32 бита на канал. Я начал искать в интернете, существует ли программы, способные преобразовывать изображения с такой точностью. К счастью, я обнаружил, что существует специальная версия ImageMagick, которая поддерживает HDRI (High dynamic-range imaging) - собственно высокоточные преобразования и расчёты. В 64-битных версиях ImageMagick, а также начиная с версии 7.0.0 этот самый HDRI включён по умолчанию. И когда я установил ImageMagick 7.0.0 x64 с HDRI и стал его использовать для преобразования 12-битных .j2c в 16-битные .png (при этом я решил больше не использовать openjpeg из OCT для преобразования кадров, так как оказалось, что можно напрямую конвертировать из j2c в png c помощью ImageMagick и качество преобразования при этом будет даже лучше), артефакты наконец пропали и все детали на тёмных участках кадра после преобразования стали сохраняться.
Попутно я заинтересовался вопросом, а как же тогда выполняют преобразование из XYZ в RGB другие программы?
Для того, чтобы это выяснить, я провёл эксперименты по преобразованию jpeg2000 кадра из XYZ в RGB (PNG) с различными степенями точности расчёта. Я сделал преобразования одного и того же кадра с точностью расчётов 8 бит на канал (использовал ImageMagick с Q8), 16 бит на канал (использовал ImageMagick с Q16) и HDRI (использовал ImageMagick с HDRI, условно назову 32 бита на канал). Также посмотрел, как выполняют преобразования LAV (через DirectShowSource или MPC-HC), ffms2. ffdshow, как я обнаружил, не умеет выполнять конвертацию jpeg2000 кадров. То есть он такие видео (mxf-файлы) вообще не может воспроизводить. В качестве тестового изображения решил взять кадр из первого трейлера "Как приручить дракона 2", поскольку там есть очень хорошие тёмные сцены с большой глубиной. Вот получившиеся изображения:
8 бит (ImageMagick Q8), искажения до 114 уровня (из 255):

16 бит (ImageMagick Q16), искажения до 8 уровня (из 255). Рядом для наглядности осветлённое через преобразование уровней 0-28 -> 0-255 изображение.

32 бита (ImageMagick HDRI), искажений нет. Рядом осветлённое через преобразование уровней 0-28 -> 0-255 изображение.

ffms2, искажения до 32 уровня (из 255). Рядом осветлённое через преобразование уровней 0-28 -> 0-255 изображение.

LAV, искажения до 32 уровня (из 255). Рядом осветлённое через преобразование уровней 0-28 -> 0-255 изображение.

И ещё просто оригинальный кадр, преобразованный из j2c ([url=http:// СПАМ на исходный файл[/url]) в PNG без преобразования гаммы и цветов (то есть без конверсии из xyz в rgb):

После сравнения изображений, полученных через ffms и LAV, с кадрами, полученными через ImageMagick с точностью расчётов 8 бит и 16 бит на канал, я сделал вывод, что расчёты для преобразования из XYZ в RGB в ffms2 и LAV ведутся с точностью 12 бит на канал. По всей видимости, те, кто делал конвертацию из XYZ в RGB в ffms2 и LAV, решили ограничиться в точности расчётов глубиной цвета jpeg2000 кадра DCP, то есть 12 бит на канал. Скриншот через ffmpeg я не стал делать, поскольку я посмотрел, как выполняются в коде расчёты для преобразования из XYZ в RGB, и понял, что там тоже 12 бит. Собственно, вот здесь на сравнении на третьей картинке тоже можно увидеть, что расчёты в ffmpeg идут в 12 бит.
Кстати, с помощью VapourSynth можно напрямую перекодировывать jpeg2000-видео из mxf в h264 10-бит 4:4:4 видео без разложения на кадры, но так как VapourSynth для этого использует плагин fmss2, то расчёты там происходят с глубиной 12 бит на канал, поэтому артефакты и бандинг на тёмных участках остаются.
То есть на данный момент пока невозможно без разложения на кадры напрямую качественно перевести 12-битное jpeg2000-видео из mxf в 10-битное h264 видео без артефактов и потери нижних битов (то есть тёмных областей кадра). По крайней мере до тех пор, пока преобразования видео не будут выполняться с точностью 32 бита на канал.

---

Итак, после всего этого я стал использовать ImageMagick с HDRI. Но на этом проблемы не закончились.
Я сделал рипы второго трейлера "Как приручить дракона 2" в 2D 4:4:4 10-бит, в вертикальной полноразмерной стереопаре 8 бит 4:2:0 и вертикальной анаморфной стереопаре 8 бит 4:2:0. При этом вертикальную полноразмерную стереопару я решил закодировать уже через VapourSynth, для этого написал специальный скрипт - чтобы закодировать видео уже с использованием дизеринга до 8 бит. Только анаморфную стереопару решил закодировать через AviSynth MeGui, как и в прошлые разы.
Аналогичным образом сделал рипы первых пяти минут. Везде уже использовал для конвертирования изображений ImageMagick с HDRI.
Я выложил рипы второго трейлера на рутрекер. А спустя пару дней вдруг увидел, что в рипах вертикальной анаморфной стереопары картинка получилась почему-то темнее, чем должна быть. o_O При этом раньше такого не было. Начав выяснять, в чём дело, я обнаружил, что AviSynth, с помощью которого я кодировал рипы в анаморфной стереопаре, ведёт себя так только с теми кадрами PNG, которые создал ImageMagick с HDRI. Я решил, что это некий странный баг чтения последовательности 16-битных PNG в AviSynth - потому что в рипе полноразмерной вертикальной стереопары, который я закодировал с помощью VapourSynth, используя те же самые файлы PNG, картинка была такая, какая должна быть. Пришлось начать писать скрипт VapourSynth для кодирования вертикальной анаморфной стереопары, чтобы потом переделать рипы. Но тут уже начались проблемы с VapourSynth и плагинами к нему. К тому времени уже вышел VapourSynth r23, и я решил обновиться. Как потом оказалось, напрасно.
Новый VapourSynth версии r23 уже поддерживал 64-разрядные ОС, в отличие от версии r19, которую я всё это время использовал. Кроме того, туда добавили возможность добавления чёрных полос. Я снёс 32-битный Python и VapourSynth r19, и установил 64-битный Python и VapourSynth r23 x64. После чего скачал и поставил новые версии плагинов для 64-битной версии VapourSynth, в том числе плагин для чтения последовательностей кадров vsimagereader.dll. Но новый VapourSynth не захотел больше читать последовательность кадров, как это ни странно, постоянно выдавая ошибку "No frame returned at the end of process". В теме плагина кто-то сообщил о той же самой проблеме (http://forum.doom9.org/showthread.php?p=1658233#post1658233). Я понял, что эта ошибка появилась после обновления либо VapourSynth либо плагина. Попробовал на всякий случай установить 32-битный Python и 32-битный VapourSynth r23, но это ничего не дало. В результате пришлось удалить VapourSynth r23 и установить старую версию r19, где плагин работал исправно.
Таким образом для меня стало более невозможным добавить через скрипт VapourSynth чёрные полосы к видео для создания правильной анаморфной стереопары с разрешением 1920х1080 (просто в r19 функция добавления чёрных полос ещё работает неправильно). Пришлось импровизировать и создавать уже готовые кадры для вертикальной анаморфной стереопары уже с помощью ImageMagick. Таким образом удалось переделать рипы в вертикальной анаморфной стереопаре второго трейлера и первых пяти минут фильма "Как приручить дракона 2", видео в которых теперь стало выглядеть нормально, и, кроме того, картинка стала смотреться лучше за счёт использования дизеринга исходника до 8 бит.
Потом я обновил раздачу второго трейлера в вертикальной анаморфной стереопаре и выложил все оставшиеся рипы на рутрекер. Попутно переделал 2D-рипы тизер-трейлера и первого трейлера уже с новыми знаниями и создал раздачу-сборник всех трёх трейлеров в Hi444PP Hi10P.
После я обнаружил, что кадры PNG, созданные ImageMagick с HDRI, также отображаются более тёмными в браузере (когда их заливаешь, например, на хостинг изображений). При этом в обычном просмотрщике изображений или Photoshop'е они отображались нормально. Я начал думать, что скорее всего что-то есть такое в самих PNG, что заставляет делать картинку более тёмной либо же наоборот делает её нормальной для просмотрщиков. Для выяснения причин начал изучать особенности сохранения формата PNG и какие у ImageMagick есть возможности по настройке сохранения изображения в этом самом формате PNG. После возни с кучей параметров у ImageMagick, когда я уж совсем было отчаялся, я наконец методом тыка каким-то образом нашёл то, что нужно. С помощью команды консоли -define png:include-chunk=none мне удалось добиться нормального отображения PNG в браузере, и не только - AviSynth тоже стал нормально их считывать без искажений.
Как оказалось, внутри PNG есть блоки данных, называющихся chunk'ами. В этих блоках может записываться информация, например, о палитре и гамме. Вероятнее всего, при конвертации ImageMagick записывал или же сохранял какую-то информацию о цвете в chunk'и в PNG, которую потом определённые программы считывали. Команда -define png:include-chunk=none же отключила добавление какой-либо информации в PNG.
Правда, на качество создания рипов это никак не повлияло. Просто нашёл истинную причину затемнения картинки в рипе вертикальной анаморфной стереопары, созданном через AviSynth. Но в любом случае команда не лишняя.

---

О DCP HQ rip maker
В результате всего этого я решил все свои наблюдения и наработки использовать для создания конвертера, предназначенного для практически автоматизированной конвертации DCP в MKV с 10-битным видео и субдискретизацией насыщенности 4:4:4 в полном цветовом диапазоне. Проще говоря, для создания высококачественных рипов с DCP (незашифрованных). Назвал я этот конвертер как "DCP HQ rip maker". Специально для этого конвертера я также скомпилировал свою собственную сборку ImageMagick 6.8.9 x64 с HDRI, которая может работать без установки. Мне пришлось его сделать эту сборку самому потому что нигде в интернете я не нашёл портативный 64-разрядный ImageMagick с поддержкой HDRI.
Скачать мой "DCP HQ rip maker" можно по следующим ссылкам: http:// СПАМ или https://mega.co.nz/#!3Y4UmYbJ!c0NtfEplxR0tkBZ0fv97YGuwNKsqQ8HCBo7TI4fUVr4
Перед тем, как начать работать с конвертером, сначала необходимо установить на компьютер Python версии 3.3.x, а после него - VapourSynth r19. Они необходимы для полноценной работы конвертера. Оба дистрибутива поставляются вместе с конвертером. Это единственное, что требуется установить. При этом сам конвертер может работать из любой папки, куда его поместят. В корневой папке конвертера есть текстовый файл с подробным описанием конвертера и инструкцией к нему, здесь я вкратце напишу основное.
Конвертер представляет собой набор скриптов (батников), куда пользователем вносятся необходимая информация о DCP и параметры кодирования рипа, а также набор программ, необходимых для конвертирования DCP и создания рипа. Достаточно только внести информацию о DCP и запустить скрипт, и спустя время получить готовый рип в контейнере MKV с 10-битным видео, субдискретизаций насыщенности 4:4:4, и звуком во FLAC. Конвертер сам извлекает JPEG2000 кадры из DCP, качественно преобразует их из цветовой модели XYZ в цветовую модель RGB без потерь информации, сохраняя получившиеся после преобразования кадры в 16-битные PNG, выполняет само кодирование последовательности кадров PNG в h264 видео, режет и кодирует звук во FLAC, и выполняет сборку получившихся файлов видео и аудио в контейнер MKV.
Возможности данного конвертера:
- Кодирование видео с глубиной цвета 8 или 10 бит (в обоих случаях с использованием дизеринга);
- Кодирование видео с субдискретизацией насыщенности 4:2:0, 4:2:2 или 4:4:4;
- Кодирование видео в стандартном цветовом диапазоне tv range (16-235) или в полном цветовом диапазоне pc range (0-255);
- Обрезка кадра DCP по ширине и по высоте;
- Изменение размера видео по заданной ширине с соблюдением пропорции и учётом обрезки кадра;
- Создание вертикальных полноразмерных и вертикальных анаморфных стереопар - со всеми возможностями по кодированию видео и редактированию размера кадра видео. Для вертикальных анаморфных стереопар скрипт кодирует звук в AC3 для обеспечения совместимости с 3D-телевизорами;
- Возможность создания рипа из уже имеющейся последовательности кадров PNG;
- Пользовательская настройка строки кодировщика x264.
Используемое программное обеспечение в конвертере: Open Cinema Tools 1.1.2, ImageMagick x64 6.8.9 Portable моей сборки с включённым HDRI, VapourSynth r19 (с плагинами vsimagereader.dll и fmtconv.dll), x264 rev2431 tMod x64 - 8 и 10 бит, eac3to 3.27, MKVToolNix v7.1.0.
Среди недостатков могу отметить использование 32-битного VapourSynth и 32-битного Python'а из-за отсутствия рабочей версии плагина vsimagereader.dll для 64-битного VapourSynth. Кроме того, используется VapourSynth старой версии r19, так как рабочего плагина чтения последовательности PNG для текущей версии VapourSynth r23 нет (на момент написания поста). Попытка спросить, когда исправят плагин в теме автора плагина на форуме doom9 ни к чему толком не привела. Также ещё один недостаток - необходимость вручную вносить некоторую информацию о DCP: прописывать пути до файлов MXF с видео и аудио, а также задавать начальный кадр видео, продолжительность видео и начало аудио. При этом можно кодировать только одну пару mxf-файлов видео и аудио, но в принципе можно последовательно соединить получившееся части с помощью MKVmerge, при условии, что все эти части кодировались с одинаковыми настройками.
Отдельно скажу про использование оперативной памяти. Для того, чтобы закодировать 10-битное видео с субдискретизацией насыщенности 4:4:4 и разрешением 2K требуется не менее 4 Гб оперативной памяти. Для того, чтобы закодировать 10-битное видео с субдискретизацией насыщенности 4:4:4 в полной стереопаре (2048х1716) и разрешением каждого ракурса 2K требуется уже не менее 8 Гб оперативной памяти. А вот для того, чтобы закодировать 10-битное видео с субдискретизацией насыщенности 4:4:4 и разрешением 4K требуется уже никак не меньше 12 Гб оперативной памяти... на что уже мой компьютер оказался не способен, поскольку у меня всего 8 Гб оперативной памяти. Однако всё же закодировать 10-битное 4:2:0 4K видео с 8 Гб оперативной памяти оказалось возможным - так как при субдискретизации насыщенности 4:2:0 разрешение двух цветоразностных составляющих в 4 раза меньше, чем разрешение яркостной составляющей, из-за чего кадр с 4:2:0 весит в два раза меньше, чем кадр с 4:4:4.
В довершение, некоторые мои примеры скриптов для VapourSynth r19: А вот также в качестве примеров готовых рипов некоторые мои DCPrip'ы трейлеров, которые я сделал в ходе тестов или же просто ради интереса. Все рипы со звуком во FLAC 5.1.
- Стражи галактики, трейлер D (2D, 2048x858, 10-bit, 4:4:4, pc range, ~37,2 Mbps avg, 475 Мегабайт);
- Малефисента, трейлер H (2D, 2048x858, 10-bit, 4:4:4, pc range, ~55500 Kbps avg, 889 Мегабайт);
- Малефисента, трейлер H (3D, 2048x1716, 10-bit, 4:2:0, pc range, ~47,77 Mbps avg, 790 Мегабайт);
- Оз: Великий и Ужасный, трейлер A (2D, 2048x858, 10-bit, 4:4:4, pc range, ~20,16 Mbps avg, 313 Мегабайт);
- Оз: Великий и Ужасный, трейлер A (3D, 2048x1716, 10-bit, 4:2:0, pc range, ~14,73 Mbps avg, 243 Мегабайт);
- Самолёты: Огонь и Вода, трейлер E (2D, 2048x858, 10-bit, 4:4:4, pc range, ~17,52 Mbps avg, 242 Мегабайт);
- Холодное сердце, трейлер G (2D, 2048x858, 10-bit, 4:4:4, pc range, ~16,19 Mbps avg, 355 Мегабайт);
- Город героев, трейлер A (2D, 2048x858, 10-bit, 4:4:4, pc range, ~61,1 Mbps avg, 768 Мегабайт);
- Мстители, трейлер F (2D, 1998x1080, 10-bit, 4:4:4, pc range, ~31,31 Mbps avg, 549 Мегабайт);
- Король Лев, трейлер A (2D, 1920x1080, 10-bit, 4:4:4, pc range, ~12,98 Mbps avg, 187 Мегабайт).
И, конечно, все мои DCPrip'ы трейлеров фильма "Как приручить дракона 2" [url=tracker.php?nm=как приручить дракона 2 dcprip]можно найти на рутрекере[/url]. Некоторые трейлеры имеют довольно шумный видеоряд, поэтому битрейт в них получился высокий.
Кроме того, на рутрекере есть несколько моих рипов с DCP 4K. Это тизер и трейлер фильма "Интерстеллар", а также трейлер фильма "Исчезнувшая". Все эти рипы имеют 10-битное 4:2:0 видео с разрешением 4K.
Оценить качество картинки в рипах можно по следующим скриншотам:

Надеюсь, что этот пост окажется в той или иной мере полезным для тех, кто хотел так или иначе делать рипы с DCP.
Добавление от 7 августа: Выше я написал, что при воспроизведении 10-битного 4:4:4 видео с выводом в цветовые пространства Y410 и Y416 (LAV и ffdshow соответственно) происходит небольшое искажение цветов из-за некорректной обработки в этих цветовых пространствах видео с полным цветовым диапазоном (pc range). Сегодня я решил обновить MadVR и проверить снова, как будет смотреться видео в цветовых пространствах Y410 и Y416 при использовании новой версии рендера MadVR. И обнаружил, что эту проблему исправили - теперь больше никаких искажений цветов нет, всё выглядит так, как должно быть. Так что теперь можно 10-битное 4:4:4 видео в полном цветовом диапазоне смотреть с правильными цветами при выводе в Y410 и Y416. Нужен только MadVR последней версии.
Кроме того, я также обнаружил, что теперь создание скриншотов через MPC-HC при использовании MadVR стало возможным.

На такой подробный материал я и не рассчитывал. Теперь более полно понимаю минусы и плюсы кодирования с x264. Спасибо. Пробую настройки и использую скрипт:

jensen123321
Пожалуйста! Да я и сам не думал, что столько всякого в итоге напишу. И что столько всякого обнаружу.
Кстати, мне больше всего понравилось качество картинки у 10-битных 4:4:4 2K рипов при использовании значений CRF около 11-12. В этом случае различия между исходником практически незаметны, и вес рипа нормальный (если только видео не шумное).
У тебя, кстати, скриншоты в JPG. Я так понимаю, эти скриншоты уже из готового рипа, созданного конвертером, и MPC-HC просто их сохранил в JPG? Лучше всего выкладывать скриншоты всегда в PNG, особенно с таких рипов.

Скоро уже закончу конвертер с поддержкой данного конвертирования. Но постоянно задаюсь вопросом: а лучше ли смотрится 10 битное видео на 8 битных мониторах и теликах, чем 8 битное видео? Несомненно метод разложения на кадры с конвертацией ImageMagick HDRI - самый лучший, но нужно ли кодировать дальше это всё в 10 бит? )

alexxdls
Конечно 10-битное видео лучше, чем 8-битное, и лучше выглядит даже на 8-битных мониторах. Дело даже не столько в количестве передаваемых цветов, сколько в том, как сжимается видео. Я лучше просто дам ссылку, здесь есть информация: https://rutr.life/forum/viewtopic.php?t=3682344 Можно и самому сделать рип с DCP с 8 битами и с 10 (с одинаковым битрейтом), и сравнить их.
Ну и в DCP всё же реальные 12 бит на канал, и неплохо передать часть такой глубины цвета через 10-битное видео. А 12-битных энкодеров x264 пока ещё нет...
Кстати, в будущем ещё можно попробовать использовать и HEVC (x265) для создания рипов с DCP, в нём планируется возможность кодирования 12-битного видео и видео с цветовой субдискретизацией 4:4:4, но он всё ещё находится в состоянии альфа-версии (и поддержки 12-битного видео и цветовой субдискретизации 4:4:4 пока ещё в нём нет).

Ну я в курсе) Это так - для примера. Надо будет еще 3d попробовать сделать. Очень да же лучше.

Если оперативной памяти хватит.
При 4 Гб можно закодировать 2D 10-бит 4:4:4 2K видео или 2D 8-бит 4:2:0 4K или 3D в полной стереопаре 10-бит 4:2:0 2K видео.
При 8 Гб можно закодировать 2D 10-бит 4:2:0 4K видео или 3D в полной стереопаре 10-бит 4:4:4 2K видео.
При 12 Гб можно закодировать 2D 10-бит 4:4:4 4K видео или 3D в полной стереопаре 10-бит 4:2:0 4K видео.
Это всё примерно.

---

Кстати, ещё забыл написать про свои тесты, в каком формате цветовой субдискретизации может показывать видео 3D-устройство в 3D-режиме.
Для этого теста я сделал специальное видео с разрешением 1920х2160 (вертикальная стереопара) в формате 4:4:4. Вот нарисованная мной картинка, открывать через Stereoscopic Player:

Я решил нарисовать все три цвета и на белом и на чёрном фоне, но, как оказалось, лучше всего смотреть на красные и синие полоски на чёрном фоне (это имеет отношение к формулам преобразования из RGB в YCrCb). Если на экране 3D-устройства в 3D-режиме чётко отображаются все горизонтальные и вертикальные полоски, а также чётко видно сетку внизу, то значит картинка отображается в формате 4:4:4. Если размыты вертикальные полоски (первый ряд) и сетка (третий ряд), а вертикальные (второй ряд) не размыты, значит в формате 4:2:2. Ну и если все красные и синие полоски размыты, то 4:2:0.
Выяснилось, что 3D-телевизор Samsung UE40D7000 показывает в 3D-режиме (Frame Packing через AMD Radeon HD 6950 с HDMI 1.4a) картинку в формате 4:2:2 - то есть полное цветовое разрешение по вертикали и половинное цветовое по горизонтали. А вот 3D-ноутбук Samsung, имеющий экран 120 Гц, показывает в 3D-режиме картинку в 4:4:4, то есть в полном цветовом разрешении.
Вообще я пытался найти информацию в интернете, в каком формате цветовой субдискретизации может передаваться картинка через Frame Packing, но что-то не нашёл, потому и решил провести тест. Если кто вдруг знает, где есть такого рода информация, просьба кинуть ссылку. Мне кажется странным, что телевизор Samsung показывает 3D-видео через Frame Packing в формате 4:2:2.

Возник вопрос, как самому разобрать файл H264 для создания данного рипа, перерыл кучу всего но найти толковое объяснение где и как не удалось. Давно делаю видео 10 бит x264, хотелось бы освоить боле продвинутый формат.

В смысле, разобрать H264? Для создания какого рипа? Может вы имеете в виду "как разобрать DCP для создания рипа в x264 Hi444PP Hi10P" или что?

Есть готовый файл h264, нужно разобрать его на изображения чтоб через проектор можно было показать. Но найти ПО для этого не могу, пробовал сделать в адоб премьер но он создает неподвижные изображения TIFF и то из формата MP4, попытка загрузить MKV провалилась.
И, да только по 1 в ручную, что не удобно. Вопрос как создать правильные и чем? Чтобы можно было в люстраторе , фотошопе отредактировать и т.д.

taretburt
Не нужен Премьер. Он в данном случае совсем лишний. Тем более с его недружбой к матрёшкам.
Вам всё и фмпег прекрасно разберёт. "-t 2" ─ это сколько секунд хотите в картинки перевести. Если надо всё, то просто уберите этот параметр.
Но тогда и %03 увеличьте до 06-07. Десятибитка небось?
А в чём смысл тогда?
Впрочем, на "потренироваться" сойдёт...

Нет, фмпег пропустил при разбивке 122 кадра выдав сообщение "Past duration 0.988.... to large" Такой вариант не подходит. Необходим формат tiff.
При детальном осмотре обнаружены так же 28 испорченных картинок.

По-моему это очевидно, что у Вас что-то с файлом. Или с версией ffmpeg.
Я у себя ни на одном mkv и mxf не смог "повторить" данной ошибки.
Проверяйте. У Вас сбой программный, а Вы на "вариант" киваете? =) Дался Вам tiff...
Но tiff, так tiff:

После запуска кодирования мпег выдает следующее
- ffmpeg -i D:\000000000001111\122.h264 -r 23.997 images%01d.tiff
Stream #0:0 -> #0:0 (h264 (native) -> mjpeg (native))
Press [q] to stop, [?] for help
Past duration 0.691246 too large
Past duration 0.890526 too large
frame= 6156 fps= 47 q=24.8 Lsize=N/A time=00:04:16.53 bitrate=N/A dup=0 drop=1529
video:290755kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Отмеченные жирным это черный фон сначала видео.
В общем после обработки картинок нужно создать файл MXF.

Да, с ffmpeg у Вас сегодня не заладилось... =)
Вы просите tiff, он делает вовсе не то.
Не понимаю, что происходит... Во втором посте (который Rishkhaan) есть ссылка на форум и 80 страниц обсуждения.

на выходе выходит tiff да вот беда в том что 4:13 сек вместо 5:17 он обработал, да и после обработки изображений Opendcp ругается на поврежденные файлы, указанны начальные, несколько в середине и в конце, хотя все те что получились были проверенны и нормально открываются. Все изображения заняли на диске 58,8 ГБ, сделать из них MXF увы не выходит.

Решил ради интереса попробовать создать DCP-пакет с помощью OpenDCP на основе 10-битного h264 видео. Создать получилось.
Вот исходное h264 10-битное 4:4:4 видео, которое я использовал для теста (это на самом деле рип с тестового DCP): https://mega.co.nz/#!7dYRXCgL!HUvHzR5bxfg0JOdMzezMfnuKl46MJGwYnjuAV_TZOmQ
Вот получившийся DCP из h264 файла: https://mega.co.nz/#!jQwWwIyD!dt_nED4iq8ju7uVkE02vRpYkAHUQ4_Sg-D7HABE2h9Q Попробуйте создать последовательность кадров tiff, скачав ffmpeg по ссылке, что я сейчас дал в сообщении под спойлером "Порядок действий", и используя приведённый мной код bat'ника. Если не поможет, значит что-то с видео (может разрешение виновато) или файлы может действительно получаются повреждёнными (как вариант, попробовать на другом диске создать tiff).
И, если что, в интернете есть много инструкции по созданию DCP, например: http://cinemaprofs.ru/viewtopic.php?f=7&t=2, http://dcinemaforum.com/forum/index.php?PHPSESSID=a54116b085ac285d874e42a3bbe6fe46&topic=6.0

Мпег не верно разобрал файл на изображения, вместо 9501, создано только 6156 кадров.
Для примера при создании звукового MXF файла, он имел длину 7932 против 6156 у видео. Какие альтернативы мпег?
Далее созданный dcp файл не воспроизводится.

taretburt
Странное видео. Откуда известно, что кадров должно получиться именно 9501? Не пробовали создавать DCP, используя какие-нибудь другие видео, в качестве теста?
ffmpeg позволяет разобрать 10-битное h264 видео на кадры с реальной глубиной цвета 10 бит, в данном случае я не знаю ему альтернатив...
Вам лучше бы попробовать обратиться на специализированные форумы, где созданием DCP занимаются уже не впервые. Там лучше скажут, что делать.

OPENDCP создает рип исключительно для просмотра на проекторе и запустить его на компьютере не возможно т.е. остается формат MXF. В сети откпал спец плеер чтобы увидеть что получилось, картинки урезанны до кубической формы, и общее качество испорченно.
Как сделать рип DCP который можно свободно смотреть?
Покопав немного нашел MJPG кодек для этой цели, но найти объяснение как им сделать увы не удалось.

Есть Stereoscopic Player, его можно скачать тут на трекере, он может проигрывать DCP, вместе со звуком. Нужно только файл mxf с видео в него кинуть. Если картинка будет маленькая, в настройках его (в Advanced Options -> Other) нужно выставить полное разрешение при декодировании, галочки напротив "Reduce quality when behind" не должно стоять. Но воспроизведение DCP требует немалых ресурсов компьютера.

Посмотрю, а вот любопытно следующее нашел в сети трейлр якобы в качестве DCPRip, что любопытно, он был собран в матрешке, разобрал его внутри оказался avi с отдельной 8 канальной дорожкой. Для его запуска особо много ресурсов не нужно. Поковырялся в настройках , но одно огорчило при сборе программа перепутала кадры местами, в средине мелькают кадры из самого начала.
.
Кароче ничего не вышло, 2 е видео взятое для примера было перекодировано не правильно все кадры перепутаны местами. Увы.

Либо халтура, либо надувательство) Я лично не понимаю, кой смысл пережимать в чистый поток rgb, а потом это дело запихивать в кодек MJPG. Я так делал раньше, когда начинал только юзать dcp,но там блин чистый поток rgb без сжатия в 2k шкалил за 700 гигабайт, а тут 4k... MJPG крут, но он сохраняя исходное качество нифига не сжимает( Да и не особо чем воспроизводиться - битрейт получается да же больше,чем в оригинальном dcp/

В общем dcp у меня получился, но есть проблема , кароче при просмотре качество отличное, но постоянно мигает изображение, кодировал несколько раз подряд без толку. Видеокарта GTX570.
Сделал gif аним чтоб вы поняли что проиходит. Это пробный dcp сделанный из одного моего рипа. Как это убрать?

Что то явно не так На стадии энкода ошибки выдавал? Если нет, то перепроверьте секвенцию (кучу картинок по кадрам) на предмет наличия повторений кадров или их не правильного порядка. Плюс ролик в студию))) Если и у меня (обычно все воспроизводит на ура) будет дергать, то дело в исходнике.

Я выше писал что кадры все по порядку, смотрел после разборки, программа выдавала ошибку во время трасфера в dcp, т.е. надпись "dcp creation error" и все. А причина ошибки не известна.
Раз уж попросили в лс кину.

Хах, ну раз так https://yadi.sk/d/_DGi_aBBegGie

Посмотрим на досуге. Спасибо.