Транскодирование видео: потоковая обработка и очередь задач

Прямой ответ

Транскодирование выполняется очередью задач с ограничением параллелизма, поэтому нагрузка на процессор не превышает доступный ресурс.

ffmpeg -i input.mp4 -c:v libx264 -preset veryfast \
  -c:a aac -movflags +faststart output.mp4

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

Очередь задач и состав обработки

Очередь определяет порядок обработки файлов, поэтому состав и последовательность задач задаются до начала транскодирования.

Постановка задачи. Файл помещается в очередь, поэтому обработка выполняется асинхронно и не блокирует запрос пользователя.

Порядок обработки. Задачи выполняются по порядку постановки либо по приоритету, поэтому срочные файлы обрабатываются первыми.

Состав очереди. Число ожидающих задач показывает объём работы, поэтому рост очереди указывает на недостаточную производительность.

Практическое следствие: транскодирование в процессе запроса блокирует обработку других запросов, поскольку кодирование занимает процессор на длительное время.

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

Параллелизм и контроль нагрузки

Число одновременно кодируемых файлов определяется доступным ресурсом, поэтому параллелизм ограничивается числом ядер либо объёмом памяти.

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

Влияние на время. Рост параллелизма сокращает общее время обработки набора, но увеличивает время отдельного файла.

Контроль нагрузки. Загрузка процессора измеряется, поэтому параллелизм подбирается по фактической нагрузке, а не по предположению.

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

Повтор после сбоя и проверка результата

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

Повтор задачи. Файл возвращается в очередь при сбое, поэтому обработка завершается без ручного вмешательства.

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

Неполный результат. Файл меньшей длительности, чем источник, указывает на обрыв обработки, который не всегда сопровождается ошибкой.

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

О потоковой передаче — в статье про медиасервер и HLS; о битрейте и качестве — в статье про сжатие видео.

Аппаратное ускорение и время обработки

Аппаратное кодирование выполняется специализированным блоком, поэтому время обработки сокращается, а процессор остаётся свободным для других задач.

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

Поддержка кодека. Не каждый кодек кодируется аппаратно, поэтому выбор кодека определяет доступность ускорения.

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

Практическое следствие: транскодирование без аппаратного ускорения занимает процессор на всё время обработки, поэтому число одновременных задач ограничивается числом ядер.

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

Практика: организация транскодирования

1. Выполняйте транскодирование через очередь задач. Обработка не блокирует запрос пользователя, поскольку выполняется асинхронно.

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

3. Подбирайте скорость кодирования под требование. Более быстрый режим сокращает время обработки при допустимом объёме.

4. Используйте приоритет для срочных файлов. Задачи обрабатываются в требуемом порядке.

5. Обеспечивайте идемпотентность задачи. Повторная постановка файла не приводит к дублированию результата.

6. Проверяйте параметры выходного файла. Длительность, кодек и размер подтверждаются по факту.

7. Настраивайте повтор при сбое. Обработка завершается без ручного вмешательства.

Рекомендации:

1. Не транскодируйте в процессе запроса. Кодирование занимает процессор на длительное время, поэтому обработка других запросов блокируется.
2. Учитывайте влияние параллелизма на время отдельного файла. Рост числа одновременных задач увеличивает время каждого.
3. Сопоставляйте очередь с производительностью. Рост числа ожидающих задач указывает на недостаточную производительность.
4. Фиксируйте параметры кодирования в конфигурации задачи. Повторная обработка даёт одинаковый результат.
5. Пересматриваем параллелизм при изменении ресурса. Новый объём процессора требует иного числа одновременных задач.

Практический сценарий: транскодирование блокировало обработку запросов

Контекст: при массовой загрузке видео сервис отвечал медленнее, а часть запросов завершалась по таймауту.

1. Диагностика. Измерение нагрузки показало, что процессы кодирования занимали все ядра процессора. Транскодирование выполнялось в процессе запроса, поэтому обработка других запросов ожидала освобождения ресурса.
2. Причина. Отсутствие очереди и ограничения параллелизма приводило к тому, что число одновременных процессов кодирования определялось числом запросов, а не доступным ресурсом.
3. Действия. (а) Перенесли транскодирование в очередь задач, чтобы кодирование выполнялось асинхронно и не блокировало запрос; (б) ограничили параллелизм числом, соответствующим доступным ядрам; (в) применили более быстрый режим кодирования, чтобы сократить время обработки отдельного файла; (г) добавили проверку параметров выходного файла, чтобы неполный результат обнаруживался; (д) настроили повтор задачи при сбое, чтобы обработка завершалась без ручного вмешательства.
4. Результат. Сервис отвечает в прежнем темпе при массовой загрузке, поскольку транскодирование выполняется асинхронно с ограниченным параллелизмом.

Вывод: транскодирование в процессе запроса занимает процессор на длительное время, поэтому обработка других запросов блокируется. Очередь задач с ограничением параллелизма по доступному ресурсу разделяет кодирование и обслуживание запросов.

FAQ

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

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

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

Что даёт флаг быстрой загрузки в контейнере? Метаданные переносятся в начало файла, поэтому воспроизведение начинается до полной загрузки файла.

Источники: FFmpeg documentation, FFmpeg codecs, ffprobe — ссылки в шапке.