Apple prores 422 hq или 422

Монтажным кодеком на платформе Apple является семейство ProRes. ProRes, как заявляет создатель, имеет такие преимущества, как:
поддержка цветового пространства 4:4:4:4 RGBA (lossless+alpha), 4:4:4 YʹCBCR и 4:2:2 YʹCBCR с проигрыванием в рилтайме;
визуальное качество некомпрессированного HD видео при скорости и размерах ниже, чем у других кодеков;
поддержка SD, HD, 2K, 4K и нестандартных размеров кадра;
кодирование в режиме переменного битрейта (VBR);
поддержка прогрессива/интерлейса;
энкодирование только в i-фреймах (intraframe).

Этот формат представлен в пяти различных вариантах: Apple ProRes 4444, Apple ProRes 422 (HQ), Apple ProRes 422, Apple ProRes 422 (LT) и Apple ProRes 422 (Proxy).
Apple ProRes 4444

Apple ProRes 4444 используют при работе с цифровыми киноматериалами от RED ONE, Thomson Viper FilmStream, Arriflex D-20/D-21 и Panavision Genesis, а так же при работе с графикой, когда нужен альфа-канал. Настройка коррекции гаммы с возможностью отключить сдвиг с 1,8 до 2,2 (такое происходит, если RGB материал с гаммой в 2,2 ошибочно интерпертирован как 1,8). Эта фича так же доступна в Apple ProRes 422.
Apple ProRes 422 (HQ)

Apple ProRes 422 (HQ) обеспечивает максимальное качество для источников с цветовым семплированием 4:2:2 и 4:2:0 (без альфаканала) и предлагает 220 Mbps (1920x1080i60).
ProRes 422 (Proxy)

ProRes 422 (Proxy) обычно используют для оффлайн или чернового монтажа на макбуках/макбуках про.
ProRes 422 (LT)

ProRes 422 (LT) был разработан для новостей, спортивных программ, а так же мультикамерных проектов, когда нужно эффективно распределять ресурсы дискового пространства, но при этом не терять в качестве (рекомендован для ТВ).

Так же можно отметить, что визуальных отличий между HQ и Proxy вы вряд ли увидите. Поэтому, если предполагается простой монтаж вполне допустимо использовать и ProRes 422 (Proxy) формат. ProRes 422 нужно использовать при кодировании из самых распространенных форматов — DVCPRO HD, XDCAM, AVCHD. Для последнего больше подойдет ProRes 422 LT. Из приведенных выше таблиц ясно, что ProRes 4444 поддерживает 12 бит, а 422 до 10 бит. На практике оптимальным кодеком для перекодировки H.264 с Canon можно считать обычный ProRes(без HQ). Дополнительно можно порекомендовать PDF-докумен, где саккумулировано огромное количество технической информации.

Что это такое Avid DNxHD?

Это монтажный кодек, разработанный компанией Avid специально для передачи и хранения HD-видеоматериала. Avid — один из лидеров рынка монтажных систем, компания производит надежные программно-аппаратные решения для телевещания, видео- и кинопроизводства, озвучания фильмов. MediaComposer, Nitris, ProTools — легендарные имена! Кодек DNxHD поддерживает весьма высокие битрейты (до 220Мбит) и глубину цвета 8 и 10 бит на канал. Также полноценно поддерживается альфа-канал. Этот кодек широко используется в монтажных системах Avid в качестве внутреннего формата хранения материала. Однако он прекрасно работает и со сторонними приложениями, к примеру, его с успехом можно применять для работы в Premiere и AfterEffects. Более подробно о кодеке и его особенностях можно прочесть на сайте производителя. Немаловажно, что исходные коды этого кодека открыты — кроме того, что этот шаг означает взаимное доверие между компанией и сообществом пользователей, это позволяет использовать реализацию кодека в сторонних приложениях, о чем речь пойдет ниже. Дистрибутивы есть для Windows и MacOS, а через ffmpeg он доступен и в GNU/Linux.
Зачем нужен Avid DNxHD?

Дело в том, что монтажные кодеки решают целый ряд проблем: — уменьшение нагрузки на процессор при монтаже (наверняка, вы уже пробовали монтировать напрямую материал с Canon 5D mark II или с Canon 7D, и скорость работы вас наверняка не порадовала); — за счет того, что компрессия минимальна и не применяется межкадровое сжатие, не только снижается вычислительная нагрузка, но и повышается надежность и стабильность работы монтажной программы; — приведение материала к единому формату перед монтажом; — хранение мастер-копий вашего фильма в высоком качестве со сравнительно небольшими затратами дискового пространства. И, что немаловажно, DNxHD бесплатен.

Avid DNxHD работает через QuickTime, что, с одной стороны, крайне удобно — он будет без проблем работать со всеми приложениями, поддерживающими импорт/экспорт в QuickTime. Что приятно, несмотря на посредничество QuickTime, экспортируемый в DNxHD материал (в большинстве случаев) лишен проблемы gamma shift.

Форматы кодирования жестко привязаны к спецификациям HD-форматов (во избежание деструктивных соблазнов, очевидно). Справа избражена «простыня» с выбором формата кодирования. Выбираем нужный вариант, убеждаемся, что настройки экспорта композиции ему не противоречат, и жмем Render (ну, или какая там в вашем любимом софте главная кнопка). Крайне важно уделить внимание работе с цветовыми пространствами, а, вернее, выбору между RGB и 601/709 при экспорте-импорте и кодировании. Игнорируя эти опции, можно сильно попортить диапазон яркостей в файле. Это касается не только работы с кодеком DNxHD.

Источник

Как Netflix упаковывает терабайтный контент с помощью облачных технологий

Netflix создаёт интересный и качественный контент, который часто собирает награды на фестивалях, так что потребности студии подталкивают технологический прогресс. Так появились облачные конвейеры постпроизводственного редактирования и совместной работы, которые требуют сложного набора функций, включая создание и размещение высококачественного прокси-контента. После получения, проверки и кодирования контента этап упаковки инкапсулирует закодированные видео и аудио в независимые от кодека медиаконтейнеры. Благодаря этому становятся доступными синхронизация аудио-видео, произвольный доступ к элементам и защита от копирования.

Необходимость поддерживать рабочие процессы ставит перед упаковочной службой новые задачи. Но это коротко. А теперь давайте поговорим об этом подробнее.

Читайте также: Рбт айфон 11 промах

Терабайтная эра

Видео, закодированное Apple ProRes, и аудио в формате PCM в контейнере Quicktime — доминирующие форматы в профессиональном постпроизводственном редактировании. Семейство кодеков ProRes обеспечивает отличную производительность редактирования и качество изображения. А ProRes 422 HQ позволяет сохранять профессиональное HD-видео без потерь качества, поэтому данный формат является отличным выбором для редактирования.

Как описано в официальном документе Apple ProRes, целевая скорость передачи данных Apple ProRes HQ для видео разрешением 1920×1080 при частоте кадров 29,97 fps составляет 220 Мбит/с. Из-за повсеместного внедрения контента 4K в производственном конвейере, поколение ProRes 422 HQ с разрешением 3840×2160 требует, чтобы конвейер обработки кодировал и упаковывал терабайтный контент. В таблице указаны примерные размеры прокси-файлов 4K ProRes 422 HQ.

Название фильма

Ирландец

История о супружестве

Повестка

Размер 4K ProRes 422 HQ

Начальная архитектура

Взглянув на диаграмму ниже, вы увидите упрощенный конвейер облачной обработки видео. Первый этап проверяет входной носитель на соответствие спецификациям доставки Netflix и генерирует обширные метаданные. Эти метаданные включают в себя информацию уровня файла (кодировку видео, частоту кадров и разрешение), и информацию уровня кадра (смещение кадра, зависимость кадра и активная область), чтобы упростить этапы обработки нисходящего потока.

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

Упрощенный конвейер обработки видео

В этой архитектуре реализовано эффективное кодирование фрагментов и обработка с помощью распределенных облачных вычислений. Однако сборка и упаковка становятся узким местом обработки, особенно когда объём файла превышает терабайт. На каждом этапе, начиная от кодирования фрагментов и заканчивая сборкой и упаковкой контента, результат предыдущего шага обработки загружается в облачное хранилище, а затем скачивается для использования на следующем этапе.

Загрузка и скачивание данных всегда сопровождаются некоторой задержкой. В то время как входные данные для кодировки, сборки и упаковки читаются параллельно благодаря MezzFS, выходные данные выгружаются только после завершения всей обработки целиком. Ниже вы увидите таблицу, в которой представлены различные этапы обработки и загрузки в виртуальные машины сборщика и упаковщика, работающего с большими медиафайлами. Стоит отметить, что облачная обработка всегда зависит от состояния сети.

Проект ProRes 422 HQ

Общая продолжительность сборки

Общая продолжительность упаковки

Важно: упаковщику по-прежнему будет требоваться доступ к локальному хранилищу для упакованных выходных данных (перед загрузкой в конечное место назначения в облаке) и любых промежуточных данных, если обработка выполняется в несколько этапов. Поскольку не все проекты исчисляются в терабайтах, то и создание огромного облачного хранилища для всех виртуальных машин упаковщика не имеет смысла. Лучше выбирать объём хранилища, отталкиваясь от фактического размера входного файла (рисунок ниже). Процессы, обрабатывающие большие файлы, направляются в виртуальные машины большого размера для хранения промежуточных результатов и упакованных выходных данных.

Рисунок 2: Облака, ресурсы и процессы

Эта архитектура была разработана, когда блочная упаковка была невозможна, а терабайтные файлы не были чем-то обычным. Сейчас понятно, что можно сэкономить на обработке данных, если избежать физической сборки закодированных фрагментов. А использование локальных хранилищ разного размера — не лучшая идея, так как реально удобно поддерживать только небольшое количество конфигураций облачных хранилищ, да и сами конфигурации периодически нужно менять, так как максимальный размер файла в каталоге неизбежно растет.

Улучшенная архитектура

Чтобы убрать ограничения существовавшей архитектуры, Нетфликс приступил к оптимизации.

Виртуальная сборка

На рисунке ниже показано, как виртуальная сборка закодированных фрагментов заменяет физическую сборку из предыдущей архитектуры. В этом подходе сборщик индексов генерирует индексный файл, поддерживая временной порядок закодированных фрагментов. Разработчики позаботились о том, чтобы все фрагменты были учтены и располагались в правильном порядке во время виртуальной сборки. Это гарантирует согласованность конечного упакованного потока и исходного файла. Индексный файл отслеживает физическое местоположение (URL) каждого фрагмента, а также физическое местоположение (URL + смещение в байтах + размер) каждого видеокадра для облегчения последующей обработки.

Главная выгода здесь в том, что любую последующую обработку видео можно абстрагировать от физического хранилища. Службы обработки мультимедиа после кодирования видео имеют «умные» загрузчики, которые используют собранный индексный файл, чтобы монтировать закодированное видео как видеокадры или закодированные фрагменты. То же самое и с упаковщиком, который считывает и записывает закодированные фрагменты только при генерации упакованных выходных данных.

Рисунок 3: Обработка видео с помощью индексации и виртуальной сборки

Виртуальная сборка значительно сокращает время ожидания при создании прокси-сервера ProRes 422 HQ Proxy, поскольку сборщик избавляется от одного цикла облачной загрузки и скачки.

Записываемая MezzFS

MezzFS – это разработанный Netflix инструмент, который позволяет монтировать объекты облачного хранилища как локальные файлы через FUSE. Благодаря этому кодировщики и упаковщики могут выполнять произвольное чтение объектов облачного хранилища без необходимости загружать весь файл перед началом обработки.

Хранение объектов в облаке не требует локального хранилища и начинается до того, как весь объект будет создан. Таким образом создание и выгрузка данных могут происходить одновременно. Существуют готовые распределенные файловые системы для облака, а также модули FUSE для S3. Вместо использования альтернативных решений компания решила улучшить MezzFZ, так как облачная система хранения, в которой упаковщик держит свои выходные данные, представляет собой службу хранилища настраиваемых объектов, построенную на основе S3 и обладающей дополнительными функциями безопасности. Это позволяет проектировать и настраивать расширения в соответствии с требованиями упаковщика и других приложений для кодирования.

Требования и задачи для поддержки операций записи отличаются от требований и задач для операций чтения. Проблемы чтения MezzFS решает с помощью метода адаптивной буферизации и региональных кэшей, которые повышают производительность системы и уменьшают затраты. Для операций записи это не используется. Более того, целью записи является создание системы, которая максимизирует потенциальную производительность упаковщика. Для этого Netflix начал с анализа шаблонов ввода-вывода упаковщика и его настройки, пытаясь сделать шаблоны более удобными для записи в облако.

У упаковщиков есть проблема: они не всегда генерируют данные линейно. Иногда они по разным причинам обновляют части файла, которые были написаны ранее. Например, как ISOBMFF (ISO / IEC 14496–12), так и Apple Quicktime используют блочные структуры для упакованных медиафайлов. Поле «moov» представляет собой заголовок метаданных, описывающих медиа, а поле «mdat» инкапсулирует медиа-контент. Блоки начинаются с заголовка, который указывает размер и тип блока перед содержимым. Когда упаковщик инкапсулирует медиаконтент в блок «mdat», размер его неизвестен, пока не будут обработаны все медиа-данные. Чтобы оптимизировать упаковщик для MezzFS с возможностью записи, Netflix отказался от использования тех функций упаковщика, которые требуют многопроходной обработки, промежуточного хранения и частого обновления заголовков.

Нам требовалось решение, которое наилучшим образом соответствовало бы шаблонам ввода-вывода упаковщика с точки зрения задержки, загрузки сети и памяти. Для этого облачное хранилище моделируется как ряд частей фиксированного размера. MezzFS поддерживает пул буферов загрузки, которые соответствуют подмножеству этих частей. Когда упаковщик создает и записывает данные в хранилище, они заполняют буферы, которые автоматически асинхронно загружаются в облако. Упаковку можно представить, как создание выходного потока, который хранится непосредственно в облаке.

Что происходит, когда упаковщик ссылается на уже загруженные байты (например, когда он обновляет размер mdat)? Любая отдельная операция чтения или записи может включать сочетание уже загруженных и не загруженных байтов. MezzFS работает по тому же принципу, что и операционные системы при обработке ошибок страниц. Он загружает части, содержащие новые загруженные байты, и сохраняет их в активном LRU-кэше. Затем операции чтения/записи упаковщика преобразуются в операции с буферами загрузки и/или буферами в активном кэше. Буферы в активном кэше выгружаются в облако по мере заполнения кэша. Как и в случае с системами управления виртуальной памятью, для определения размера активного кэша и производительности работает принцип локальности ссылок. Если упаковщик обновляет случайные, несвязанные части файла слишком часто и быстро, то произойдет сбой и производительность снизится. Анализ паттернов ввода-вывода упаковщика показал, что он делает обновления в основном, по несколько частей за раз, что делает данное решение жизнеспособным.

Рисунок 4: Обзор проекта MezzFS с возможностью записи

Использование MezzFS не обходится без затрат с точки зрения производительности. Использование FUSE предполагает, что файловые операции должны проходить через MezzFS, а не напрямую в ядре. По мере внедрения более быстрой дисковой технологии NVMe, эти затраты становятся все более заметными, но они компенсируются временем, сэкономленным за счет загрузки при упаковке. Как показано на рисунке ниже, упаковка с использованием другого локального хранилища, например, AWS Elastic Block Store (EBS) с последующей загрузкой занимает больше времени, чем аналогичная с твердотельным накопителем NVMe.

Рисунок 5: Сравнение производительности заданий упаковщика при использовании MezzFS с возможностью записи

Однако экономия времени — не единственный фактор, который нужно учитывать. Использование MezzFS с возможностью записи дает ещё одно преимущество. Оно не требует большого размера диска. Большие и быстрые диски – это дорого, к тому же конфигурации с разноразмерными дисками затрудняют планирование ресурсов и совместное использование.

Заключение

Поддержка упаковки медиа-контента терабайтных размеров является сложной задачей. Однако благодаря инновациям в области системной архитектуры, проектирования платформ и базовых инструментов теперь она поддерживается с большей эффективностью.

Общая скорость обработки видео ProRes увеличена с 50 ГБ в час до 300 ГБ в час. С другой стороны, соотношение времени обработки и времени просмотра фильма уменьшается с 6:1 до примерно 1: 1. Это значительно повышает эффективность создания высококачественных прокси-серверов Studio и уменьшает время задержки.

Помимо повышения скорости, пропадает необходимость хранить различные конфигурации локального хранилища для облачных упаковщиков. Все виртуальные машины облачного упаковщика теперь используют единую очередь планирования с оптимизированным использованием вычислительных ресурсов. Также нет необходимости в многотерабайтном локальном хранилище, можно не бояться неожиданных сбоев обработки. Одноразмерное хранилище на локальном диске является перспективным вариантом для долгих фильмов с более высоким разрешением.

Источник

Apple prores 422 hq или 422

About Apple ProRes

Apple ProRes 4444 XQ*

Apple ProRes 4444*