Netflix создаёт интересный и качественный контент, который часто собирает награды на фестивалях, так что потребности студии подталкивают технологический прогресс. Так появились облачные конвейеры постпроизводственного редактирования и совместной работы, которые требуют сложного набора функций, включая создание и размещение высококачественного прокси-контента. После получения, проверки и кодирования контента этап упаковки инкапсулирует закодированные видео и аудио в независимые от кодека медиаконтейнеры. Благодаря этому становятся доступными синхронизация аудио-видео, произвольный доступ к элементам и защита от копирования.
Необходимость поддерживать рабочие процессы ставит перед упаковочной службой новые задачи. Но это коротко. А теперь давайте поговорим об этом подробнее.
Терабайтная эра
Видео, закодированное Apple ProRes, и аудио в формате PCM в контейнере Quicktime — доминирующие форматы в профессиональном постпроизводственном редактировании. Семейство кодеков ProRes обеспечивает отличную производительность редактирования и качество изображения. А ProRes 422 HQ позволяет сохранять профессиональное HD-видео без потерь качества, поэтому данный формат является отличным выбором для редактирования.
Как описано в официальном документе Apple ProRes, целевая скорость передачи данных Apple ProRes HQ для видео разрешением 1920x1080 при частоте кадров 29,97 fps составляет 220 Мбит/с. Из-за повсеместного внедрения контента 4K в производственном конвейере, поколение ProRes 422 HQ с разрешением 3840x2160 требует, чтобы конвейер обработки кодировал и упаковывал терабайтный контент. В таблице указаны примерные размеры прокси-файлов 4K ProRes 422 HQ.
Название фильма | Ирландец | История о супружестве | Повестка
|
Продолжительность | 3,5 ч | 2 ч | 2,5 ч |
Размер 4K ProRes 422 HQ | > 1,5TB | > 1TB | > 1TB |
Начальная архитектура
Взглянув на диаграмму ниже, вы увидите упрощенный конвейер облачной обработки видео. Первый этап проверяет входной носитель на соответствие спецификациям доставки Netflix и генерирует обширные метаданные. Эти метаданные включают в себя информацию уровня файла (кодировку видео, частоту кадров и разрешение), и информацию уровня кадра (смещение кадра, зависимость кадра и активная область), чтобы упростить этапы обработки нисходящего потока.
После этапа проверки активируется функция масштабирования в облаке, которая позволяет разделить видео на фрагменты и обеспечить параллельное кодирование фрагментов в нескольких виртуальных машинах. Когда фрагменты закодированы, они сшиваются обратно в финальный кодированный битовый поток. На этом этапе в дело вступает упаковщик, который делает контент готовым к использованию клиентами.
В этой архитектуре реализовано эффективное кодирование фрагментов и обработка с помощью распределенных облачных вычислений. Однако сборка и упаковка становятся узким местом обработки, особенно когда объём файла превышает терабайт. На каждом этапе, начиная от кодирования фрагментов и заканчивая сборкой и упаковкой контента, результат предыдущего шага обработки загружается в облачное хранилище, а затем скачивается для использования на следующем этапе.
Загрузка и скачивание данных всегда сопровождаются некоторой задержкой. В то время как входные данные для кодировки, сборки и упаковки читаются параллельно благодаря MezzFS, выходные данные выгружаются только после завершения всей обработки целиком. Ниже вы увидите таблицу, в которой представлены различные этапы обработки и загрузки в виртуальные машины сборщика и упаковщика, работающего с большими медиафайлами. Стоит отметить, что облачная обработка всегда зависит от состояния сети.
Проект ProRes 422 HQ | Общая продолжительность сборки | Длительность загрузки | Общая продолжительность упаковки | Длительность загрузки |
584 GB/4k/2 часа | 4 ч. 50 мин. | 2 ч. 30 мин. | 4 ч. 50 мин. | 1 ч. 40 мин. |
350 GB/4k/2 часа | 3 ч. 11 мин. | 1 ч. | 3 ч. | 30 мин. |
Важно: упаковщику по-прежнему будет требоваться доступ к локальному хранилищу для упакованных выходных данных (перед загрузкой в конечное место назначения в облаке) и любых промежуточных данных, если обработка выполняется в несколько этапов. Поскольку не все проекты исчисляются в терабайтах, то и создание огромного облачного хранилища для всех виртуальных машин упаковщика не имеет смысла. Лучше выбирать объём хранилища, отталкиваясь от фактического размера входного файла (рисунок ниже). Процессы, обрабатывающие большие файлы, направляются в виртуальные машины большого размера для хранения промежуточных результатов и упакованных выходных данных.
Эта архитектура была разработана, когда блочная упаковка была невозможна, а терабайтные файлы не были чем-то обычным. Сейчас понятно, что можно сэкономить на обработке данных, если избежать физической сборки закодированных фрагментов. А использование локальных хранилищ разного размера — не лучшая идея, так как реально удобно поддерживать только небольшое количество конфигураций облачных хранилищ, да и сами конфигурации периодически нужно менять, так как максимальный размер файла в каталоге неизбежно растет.
Улучшенная архитектура
Чтобы убрать ограничения существовавшей архитектуры, Нетфликс приступил к оптимизации.
Виртуальная сборка
На рисунке ниже показано, как виртуальная сборка закодированных фрагментов заменяет физическую сборку из предыдущей архитектуры. В этом подходе сборщик индексов генерирует индексный файл, поддерживая временной порядок закодированных фрагментов. Разработчики позаботились о том, чтобы все фрагменты были учтены и располагались в правильном порядке во время виртуальной сборки. Это гарантирует согласованность конечного упакованного потока и исходного файла. Индексный файл отслеживает физическое местоположение (URL) каждого фрагмента, а также физическое местоположение (URL + смещение в байтах + размер) каждого видеокадра для облегчения последующей обработки.
Главная выгода здесь в том, что любую последующую обработку видео можно абстрагировать от физического хранилища. Службы обработки мультимедиа после кодирования видео имеют «умные» загрузчики, которые используют собранный индексный файл, чтобы монтировать закодированное видео как видеокадры или закодированные фрагменты. То же самое и с упаковщиком, который считывает и записывает закодированные фрагменты только при генерации упакованных выходных данных.
Виртуальная сборка значительно сокращает время ожидания при создании прокси-сервера 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-кэше. Затем операции чтения/записи упаковщика преобразуются в операции с буферами загрузки и/или буферами в активном кэше. Буферы в активном кэше выгружаются в облако по мере заполнения кэша. Как и в случае с системами управления виртуальной памятью, для определения размера активного кэша и производительности работает принцип локальности ссылок. Если упаковщик обновляет случайные, несвязанные части файла слишком часто и быстро, то произойдет сбой и производительность снизится. Анализ паттернов ввода-вывода упаковщика показал, что он делает обновления в основном, по несколько частей за раз, что делает данное решение жизнеспособным.
Использование MezzFS не обходится без затрат с точки зрения производительности. Использование FUSE предполагает, что файловые операции должны проходить через MezzFS, а не напрямую в ядре. По мере внедрения более быстрой дисковой технологии NVMe, эти затраты становятся все более заметными, но они компенсируются временем, сэкономленным за счет загрузки при упаковке. Как показано на рисунке ниже, упаковка с использованием другого локального хранилища, например, AWS Elastic Block Store (EBS) с последующей загрузкой занимает больше времени, чем аналогичная с твердотельным накопителем NVMe.
Однако экономия времени — не единственный фактор, который нужно учитывать. Использование MezzFS с возможностью записи дает ещё одно преимущество. Оно не требует большого размера диска. Большие и быстрые диски – это дорого, к тому же конфигурации с разноразмерными дисками затрудняют планирование ресурсов и совместное использование.
Заключение
Поддержка упаковки медиа-контента терабайтных размеров является сложной задачей. Однако благодаря инновациям в области системной архитектуры, проектирования платформ и базовых инструментов теперь она поддерживается с большей эффективностью.
Общая скорость обработки видео ProRes увеличена с 50 ГБ в час до 300 ГБ в час. С другой стороны, соотношение времени обработки и времени просмотра фильма уменьшается с 6:1 до примерно 1: 1. Это значительно повышает эффективность создания высококачественных прокси-серверов Studio и уменьшает время задержки.
Помимо повышения скорости, пропадает необходимость хранить различные конфигурации локального хранилища для облачных упаковщиков. Все виртуальные машины облачного упаковщика теперь используют единую очередь планирования с оптимизированным использованием вычислительных ресурсов. Также нет необходимости в многотерабайтном локальном хранилище, можно не бояться неожиданных сбоев обработки. Одноразмерное хранилище на локальном диске является перспективным вариантом для долгих фильмов с более высоким разрешением.
