Розробка конвеєра транскодування відео FFmpeg

Користувачі завантажують відео в чому завгодно — MOV з iPhone, MKV з торента, AVI з 2008 року. Завдання бекенду — прийняти це, віддати в браузер нормальний MP4/H.264 або WebM/VP9, не блокуючи веб-процес на хвилини транскодування. Ми спроєктували відмовостійкий пайплайн, який використовується в продакшені не один рік — реалізували його для понад 30 проєктів. Результат: адаптивні профілі якості, прогрес у реальному часі, сповіщення про готовність. Типова економія на серверних ресурсах сягає 40%, а вартість CDN-трафіку знижується суттєво.

Чому синхронне транскодування — погана ідея?

Транскодування відео — CPU-інтенсивна операція, яка триває від секунд до десятків хвилин залежно від довжини ролика та профілю кодування. Синхронна обробка в HTTP-запиті виключена: вона заблокує веб-воркер, призведе до тайм-аутів і падіння чуйності. Правильний підхід — асинхронна черга завдань. Апаратне кодування NVENC обробляє відео в 3 рази швидше за програмне, але навіть воно не повинно блокувати запит.

Як побудувати пайплайн транскодування?

Архітектура включає кілька компонентів. Нижче — покроковий процес:

1. Завантаження: файл зберігається в об'єктне сховище або на локальний диск, повертається ID завдання.
2. Черга: ставимо Job у чергу (RabbitMQ, Redis, SQS), щоб не блокувати HTTP-запит.
3. Воркер: забирає Job, запускає FFmpeg з потрібними параметрами, пише прогрес у Redis.
4. Сповіщення: після завершення оновлюємо БД і оповіщаємо клієнта через WebSocket або polling.

Типовий набір профілів для адаптивної трансляції:

CRF (Constant Rate Factor) — основний параметр якості для H.264: 18 = майже без втрат, 28 = прийнятна якість при малому розмірі. preset впливає на швидкість кодування vs розмір файлу.

Як відстежувати прогрес транскодування?

FFmpeg вміє виводити прогрес через pipe. Воркер парсить рядки формату out_time_usec=... і зберігає відсотки в Redis. Клієнт отримує оновлення через WebSocket (наприклад, Laravel Echo) або polling. Це дозволяє показувати точний прогрес без затримок. Механізм progress описаний в документації FFmpeg.

Вибір контейнера залежить від завдань: MP4 універсальний для стрімінгу, WebM з VP9 дає краще стиснення, MKV підходить для архівного зберігання з субтитрами. Для вебу ми рекомендуємо MP4 з H.264 — браузери не вимагають плагінів.

Як реалізувати сервіс запуску FFmpeg?

Ключовий елемент — сервіс, який керує процесом FFmpeg з обробкою прогресу:

namespace App\Services;

class FfmpegService
{
    public function transcode(
        string $inputPath,
        string $outputPath,
        array  $profile,
        ?callable $onProgress = null
    ): void {
        $width   = $profile['width'];
        $height  = $profile['height'];
        $videoBr = $profile['video_br'];
        $audioBr = $profile['audio_br'];
        $preset  = $profile['preset'];
        $crf     = $profile['crf'];

        // scale зі збереженням співвідношення сторін, padding до потрібного розміру
        $scaleFilter = "scale={$width}:{$height}:force_original_aspect_ratio=decrease,"
            . "pad={$width}:{$height}:(ow-iw)/2:(oh-ih)/2:black";

        $cmd = implode(' ', [
            'ffmpeg -y',
            "-i " . escapeshellarg($inputPath),
            "-vf " . escapeshellarg($scaleFilter),
            "-c:v libx264",
            "-preset {$preset}",
            "-crf {$crf}",
            "-maxrate {$videoBr}",
            "-bufsize " . (intval($videoBr) * 2) . "k",
            "-c:a aac",
            "-b:a {$audioBr}",
            "-movflags +faststart",
            "-progress pipe:1",
            "-loglevel error",
            escapeshellarg($outputPath),
        ]);

        $descriptors = [
            0 => ['pipe', 'r'],
            1 => ['pipe', 'w'],
            2 => ['pipe', 'w'],
        ];

        $proc = proc_open($cmd, $descriptors, $pipes);
        // ... читання прогресу та перевірка коду виходу
    }
}

-movflags +faststart — обов'язковий флаг: він переміщує атом moov на початок MP4, дозволяючи браузеру почати відтворення до повного завантаження. Без нього відео не почнеться, доки не завантажиться весь файл.

Як вибрати між програмним та апаратним кодуванням?

Програмне кодування (libx264) дає кращу якість на низьких бітрейтах, але повільніше. Апаратне (NVENC) швидше, але може погіршити якість при сильному стисненні. Порівняння:

Для продакшену часто комбінують: NVENC для попереднього перегляду, libx264 для фінального архіву. Оптимальний вибір залежить від ваших пріоритетів: швидкість чи якість.

Що входить у роботу

В рамках розробки конвеєра транскодування ми надаємо:

• Налаштування черг (RabbitMQ/Redis) та supervisor для воркерів.
• Реалізація сервісу FFmpeg з парсингом прогресу.
• Створення Job-класів з обробниками успіху/помилок.
• Конфігурація профілів транскодування під ваші завдання.
• Ендпоінти для отримання прогресу та результату.
• Інтеграція WebSocket-сповіщень (опціонально).
• Документація з розгортання та моніторингу.

Терміни та як замовити

Розробка базового пайплайна займає від 2 до 4 днів залежно від складності профілів та необхідності WebSocket. Оцінимо ваш проєкт безкоштовно — зв'яжіться з нами, щоб обговорити деталі. Ми гарантуємо якість коду та підтримку після здачі. Зв'яжіться для консультації!

Використовуйте ці рекомендації — і пайплайн працюватиме стабільно навіть під високим навантаженням.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.