Apple prores 422 apple prores 4444

Всё, что нужно знать про кодек Apple ProRes для видео в iPhone. Это вам не в Инстаграм снимать

На презентации новых iPhone 13 Pro купертиновцы показали новую возможность флагманов – съемку роликов в формате ProRes. Фишку не успели доделать к старту продаж моделей, она стала доступна лишь с выходом ключевого обновления iOS 15.1.

Опция стала большим шагом вперед в развитии мобильной видеосъемки. В свое время в Apple уже создавали подобные прорывные технологии для фото вроде портретной съемки в iPhone 7 Plus или Apple ProRAW в iPhone 12 Pro.

Сейчас разберемся, есть ли смысл записывать видео в ProRes на iPhone. Какие преимущества и перспективы у данного кодека в мире мобильной видеосъемки?

Что такое Apple ProRes

Apple ProRes – это не один, а целое семейство кодеков, которые используются для сжатия видео. Кодеки разработаны компанией Apple и впервые были представлены в одном из обновлений приложения Final Cut для Mac в 2007 году.

Кодеки ProRes основаны на дискретно-косинусном алгоритме преобразования данных и используют одновременно несколько методов сжатия видеопотока.

Есть несколько разновидностей кодека ProRes.

◉ Apple ProRes 4444 XQ: самый топовый 12-битный кодек без сжатия, который поддерживает высокую скорость видеопотока, широкий динамический диапазон и альфаканал.

◉ Apple ProRes 4444: это 12-битный кодек без сжатия, который поддерживает цветовые пространства RGB/Y’CrCb и умеет хранить данные о прозрачности (альфаканал).

◉ Apple ProRes 422 (HQ): это 10-битный кодек высокого разрешения (вплоть до 8К), который имеет более высокий битрейт и качество картинки.

◉ Apple ProRes 422: аналог предыдущего 10-битного кодека, но с более низким качеством картинки и скоростью видеопотока.

◉ Apple ProRes 422 (LT): еще более облегченный вариант 10-битного кодека, который балансирует на грани качества картинки и размера исходного файла.

◉ Apple ProRes 422 (Proxy): кодек с довольно низкой скоростью видеопотока, который в основном используется для чернового монтажа.

Основные отличия и предназначения разных видов кодека ProRes

Семейство кодеков Apple при полной поддержке программной и аппаратной платформ обеспечивает быструю и удобную работу с видеоматериалом. Данные в ProRes практически не требуют ресурсов устройства для распаковки, что ускоряет процесс монтажа. Особенно это заметно при работе с несколькими потоками одновременно.

Кроме того, ролики в ProRes хранят большой объем информации о цвете, как и фотографии в ProRaw, позволяя на стадии монтажа вытягивать слишком темные или, наоборот, засвеченные участки кадра.

Расплатой за эти преимущества является размер файлов, отснятых в ProRes.

Купертиновцы продают лицензии на кодирование и декодирование в кодек ProRes, благодаря чему он стал довольно популярным форматом хранения данных. Определенные камеры производителей Blackmagic, Canon, DJI, Panasonic, Sony и других умеют сохранять отснятый материал в ProRes.

Полный список производителей и моделей камер с поддержкой Apple ProRes можете просмотреть здесь.

Осенью 2021 года к списку поддерживаемого оборудования добавились смартфоны Apple.

Какие особенности и ограничения есть у ProRes на iPhone

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

Во-первых, кодек ProRes поддерживается только в моделях iPhone 13 Pro и iPhone 13 Pro Max .

Во-вторых, как уже было сказано выше, видео в формате ProRes занимают очень много места на устройстве . Минутный ролик в 4K разрешении будет занимать около 6 ГБ. Из-за этого в Apple ограничили максимально доступное разрешение для съемки в ProRes на моделях iPhone 13 Pro с минимальным объемом памяти.

Накопителя на 128 ГБ могло бы хватить для сохранения всего 18-19 минут видео в ProRes 4K. Базовая “прошка” умеет снимать ProRes в разрешении 1080p. Смартфон Apple с максимально возможным объемом памяти в 1 ТБ способен уместить чуть более 2.5 часов видео в ProRes с разрешением 4K.

В-третьих, отснятый материал в ProRes рано или поздно придется передавать на компьютер для дальнейшей обработки и монтажа . А здесь все упирается в старый добрый Lightning, который явно выбивается из «профессиональной» направленности iPhone 13 Pro.

Стандартный разъем iPhone, который не менялся с 2012 года, позволяет передать около 3.5 Гб данных в минуту. Это значит, что минутное видео в ProRes будет передаваться около 3 минут, а часовой ролик – почти 3 часа!

В-четвертых, ProRes поддерживают не все устройства Apple . Соответственно, при передаче данных по AirDrop ролики могут быть автоматически перекодированы в H.264 или HEVC.

Это нужно помнить при попытке перебросить большой объем данных по воздуху.

Передать ProRes без конвертации можно на такие устройства:

◈ Всю линейку iPhone 13 (включая модели iPhone 13 mini и iPhone 13);
◈ iPad mini (6-го поколения);
◈ iPad Pro (11″ всех поколений или 12.9″ 3-го поколения и новее);
◈ Компьютеры Mac с OS X 10.6 и новее.

Эти устройства смогут сохранять ProRes без перекодирования, просматривать и редактировать видео.

В-пятых, изначально флагманские модели iPhone снимают с использованием кодека Apple ProRes 422 (HQ). Это один из трех видов кодека без сжатия, но, в отличие от ProRes 4444 и ProRes 4444 XQ, он не умеет хранить данные об альфаканале и записывает до 10 бит.

Сторонние приложения для съемки видео позволяют активировать кодеки со сжатием: ProRes 422, 422 (LT) или 422 (Proxy).

Как снимать в ProRes на iPhone

Работает данная фишка только на моделях iPhone 13 Pro и iPhone 13 Pro Max с установленной операционной системой iOS 15.1 и новее.

1. Перейдите в Настройки – Камера – Форматы.

2. Активируйте переключатель Apple ProRes в разделе Видеосъемка.

3. Включите приложение Камера в режиме съемки Видео и активируйте кнопку ProRes в верхней панели.

Обратите внимание, что съемка в ProRes невозможна в режиме «Киноэффект», при замедленной съемке или покадровом режиме.

Видеоролики могут быть сняты в разрешении 1080p 25/30/60 кадров в секунду или 4K 24/25/30 кадров в секунду.

Не забывайте, что модели с минимальным объемом памяти не могут записывать ProRes ролики в 4K.

Съемка в ProRes в приложении FiLMiC Pro

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

Например, такая возможность появилась в одном из последних обновлений FiLMiC Pro.

Нужен ли ProRes в текущем поколении iPhone

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

Новые модели iPhone 13 Pro получили поддержку кодека ProRes, но выглядит это новшество не сиюминутным бонусом, а фишкой на перспективу.

Сейчас даже при самом пристальном сравнении найти отличие между снятыми с использованием разных кодеков роликами найти непросто. Многократное увеличение, попытка найти различия в динамических сценах, агрессивная цветокоррекция или перекраска кадра пока не позволяют выявить серьезные плюсы роликов в ProRes.

Матрица iPhone еще не способна предоставить такой большой объем информации и данных, чтобы был смысл кодировать ее в профессиональный видеокодек .

Наглядное сравнение видео в ProRes и HEVC. Найдите 10 отличий.

Через два-три года, когда матрица и используемая оптика пройдут еще несколько стадий эволюции, мы обязательно получим профит от ProRes кодека в iPhone.

А пока, если вы не суперпрофессионал, использовать ProRes в текущем поколении «прошек» нет особой необходимости. Вы быстрее заполните память смартфона, а затем потратите больше времени на передачу контента на компьютер для дальнейшей обработки.

Источник

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

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

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

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

Видео, закодированное 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 и уменьшает время задержки.

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

Источник