Итак, мы имеем следующие константы:

• На входе
• High Definition видео, к примеру 1920x1080 30Mbps
• На выходе:
• Экран с низким (по сравнению с HD) разрешением. Чтобы исключить затраты на масштабирование и связанных с ним искажений картинки, рекомендуется использовать «родное» разрешение экрана, скажем 640x480
• Энергосберегающая платформа. Скорость декодирования чувствительна к bit rate, поэтому мы не должны задирать этот параметр, чтобы видео игралось гладко без дёрганий (1Mbps или меньше, например)
• Ограниченный объём памяти. Мы должны позаботиться, чтобы все выбранные нами фильмы убрались на диск / флэшку

Переменные:

• Параметры энкодера
• Процесс преобразования используемый в нашем примере называется транскодированием. Обычно его запускают на мощных компьютерах, и мы можем балансировать длительностью процесса, размером получаемых файлов и качеством видео. Ключевые переменные тут bit rate и target usage. Bit rate задаёт количество бит для одной секунды видео потока, а target usage определяет такие параметры как: количество опорных кадров, метод поиска motion estimation векторов, метод упаковки и так далее

И основные взаимосвязи:

• Чем больше bit rate, тем:
• выше качество видео, дольше процесс, больше размер файла
• ниже скорость декодирования
• Чем выше target usage, тем:
• выше качество видео, дольше процесс, а размер файла такой же
• ниже скорость декодирования

Используя асинхронную модель, предлагаемую Intel® Media SDK, операции Decode, Video Pre Processing (VPP) и Encode в приложениях выполняется параллельно. Это позволяет хорошо использовать вычислительные ресурсы для заданных параметров кодирования. К сожалению, не существует автоматического способа подбора оптимальных параметров для конкретной платформы и пользователя. Поэтому я часто наблюдаю, что процессор простаивает при транскодировании High Definition в Low Resolution с параметрами по умолчанию (Диаграмма 1)

Диаграмма 1: Транскодирование High Definition в Low Resolution видео с параметрами по умолчанию может терять значительную часть вычислительных ресурсов

В этом выдуманном примере Encode обрабатывает данные быстрее, чем Decode и VPP. Поэтому простаивают ресурсы CPU. В результате качество картинки может быть далеко от совершенства (Рисунок 1).

Рисунок 1: При транскодировании с параметрами по умолчанию качество картинки может быть низким

Как Вы видите, в нашем примере процесс работает со скоростью самой медленной компоненты Decode. Воспользуемся же этим и подкрутим параметры Encode, чтобы получить более качественную картинку при той же скорости просто нагружая незадействованные ресурсы. Это означает, что в нашем случае более сложные алгоритмы кодирования могут быть использованы для улучшения результата на халяву (Рисунок 2). Настройка проводится подбором значений переменных bit rate и target usage, помня, что они оба нагружают декодер, улучшая качество; а размер файла линейно зависит от bit rate и практически не зависит от target usage. Я советую произвести несколько пристрелочных запусков транскодирования небольшого отрывка в несколько секунд с различными настройками, чтобы выбрать подходящие. Для оценки загрузки CPU можно воспользоваться приложением Windows Task Manager и убедиться, что процессор загружен полезной работой. (Диаграмма 2). Как только соотношение качества видео / размера файла / продолжительности процесса Вас устраивают можно запускать транскодирование в пакетном режиме и заняться другими делами (например, позвонить родителям).

Диаграмма 2: Транскодироавание с оптимальными настройками загружает теряемые ранее ресурсы полезной работой

Рисунок 2: При транскодировании с оптимальными настройками получаем значительно лучшее качество, не теряя в скорости

В заключение отмечу, что используя Intel® Media SDK и простые приёмы, достаточно легко получить великолепное качество видео при решении Ваших задач транскодирования.

Слава

P.S. Ни одна рыбка не пострадала при съёмках материалов для этого блога.

Это третья публикация из серии. Вы можете ознакомиться с предыдущими частями тут: Эпизод 1 и Эпизод 2. В этой части я расскажу, как с использованием Intel® Media SDK достичь высокой производительности видео транскодирования на платформах с аппаратным ускорением графики.

Чтобы объединить сильные стороны ранее рассмотренных моделей: простоту реализации однопотоковой модели и высокую производительность многопотоковой, Intel® Media SDK предлагает асинхронную модель. Рассмотрим подробнее, как это работает: последовательность кадров посылается в асинхронную цепочку на обработку, а синхронизация происходит в самом конце на выходе после Encode. При этом Intel® Media SDK полностью контролирует поток данных и зависимости между компонентами. В дополнение к оптимальному распараллеливанию, Intel® Media SDK предоставляет приложениям лёгкий способ воспользоваться ресурсами платформы при помощи аппаратно ускоренных (если это поддерживается оборудованием) и программно оптимизированных компонент Decode, VPP и Encode.

Диаграмма 1: Intel® Media SDK асинхронная обработка кадров

Диаграмма загрузки ресурсов аналогична синхронной многопоточной модели.

Диаграмма 2: Асинхронная модель теряет незначительную часть ресурсов

Ниже приведён псевдо-код, чтобы показать, как просто реализовать асинхронную модель в приложениях. Достаточно организовать один поток, который содержит 4 стадии обработки. Первые три стадии используют логику “for each frame ready for ...”. “ready” здесь означает, что доступно достаточное количество данных и не возникало ошибок на предыдущих стадиях.

1. Первый цикл получает входные данные и ставит их в очередь Decode, пока имеются свободные входные буфера. Информация об успешно принятых кадрах сохраняется в специальном массиве. Этот массив содержит указатели на 3 буфера (surfaces) и 3 точки синхронизации (sync points) для каждого кадра. Указатели на буфера требуются для передачи кадра следующим по цепочке компонентам, а точки синхронизации нужны для обработки ошибок.
2. Второй цикл использует информационный массив, чтобы поставить кадры в очередь VPP и сохранить информацию об этом в случае успеха.
3. Третий цикл поступает аналогично с Encode.
4. Последний цикл перебирает все точки синхронизации, полученные от Encode, и проверяет кадры на готовность. Все успешно обработанные кадры сбрасываются в выходной поток, а информация о них удаляется из информационного массива. Если при транскодировании произошла ошибка, приложение должно определить место, где это случилось, устранить проблему и, в случае успеха, послать данные на обработку повторно. Это возможно только при хранении всех точек синхронизации возвращённых асинхронными функциями. Например, если VPP вернул ошибку, приложение должно её устранить и послать соответствующий кадр (и все последующие) на обработку VPP и Encode повторно.

while (there are frames to process)
{
    // Submit multiple frames to a Decode queue
    for each frame ready for Decode
    {
        if (there is no free Decode buffer) break;

        status = DecodeFrameAsync(); // submit a frame to Decode

        // Save a surface and sync info into the info array on success
        if (status ==       Success) SaveFrameInfo();
        if (status ==    FatalError) return Error;
        if (status == NonFatalError) FixDecodeError();
    }

    // Submit multiple frames to a VPP queue
    for each frame ready for VPP
    {
        if (there is no free output buffer) break;

        status = RunFrameVPPAsync(); // submit a frame to VPP

        // Save a surface and sync info into the info array on success
        if (status ==       Success) SaveFrameInfo();
        if (status ==    FatalError) return Error;
        if (status == NonFatalError) FixVPPError();
    }

    // Submit multiple frames to a Encode queue
    for each frame ready for Encode
    {
        if (there is no free output buffer) break;

        status = EncodeFrameAsync(); // submit a frame to Encode

        // Save a sync info into the info array on success
        if (status ==        Success) SaveFrameInfo();
        if (status ==     FatalError) return Error;
        if (status ==  NonFatalError) FixEncodeError();
    }

    // Multiple Syncs & Error handling
    for each Sync point received from Encode
    {
        status = SyncOperation(no_wait);

        // Write output bitstream and remove the info array record on success
        if (status ==       Success) { WriteFrame(); RemoveFrameInfo(); }
        if (status ==    FatalError) return Error;
        if (status == NonFatalError) DetectAndFixTranscodeError(); // Error handling
    }

    Sleep();
}

return Success;

Как Вы видите, Intel® Media SDK значительно облегчает жизнь разработчикам видео транскодеров. Давайте потратим сэкономленное время с пользой и подумаем, как ещё уменьшить простой ресурсов или избавиться от него полностью?

Слава.

Это вторая публикация из серии (с первой частью можно ознакомиться тут: Эпизод 1). Здесь я опишу некоторые советы по оптимизации однопотоковой модели видео транскодирования и проиллюстрирую почему с их применением на платформах с аппаратным ускорением графики значительно повышается производительность.

Многопотоковость – основной путь к оптимальному использованию вычислительных ресурсов. Приложение выполняет Decode, VPP и Encode в отдельных потоках позволяя им работать параллельно и начинать обработку кадра немедленно, как только данные готовы и ресурс свободен. Диаграмма 1 иллюстрирует, чем данная модель отличается от однопотоковой.

Диаграмма 1: Многопотоковая обработка кадров

Параллельное выполнение в этой модели значительно улучшает загрузку ресурсов. Decode завершив обработку кадра передаёт его VPP и немедленно начинает декодирование следующего. Тоже самое происходит на связке VPP и Encode. Ниже приведён пример параллельной работы компонент транскодирующей цепочки.

Диаграмма 2: Многопотоковая модель теряет гораздо меньше вычислительных ресурсов

В этом вымышленном примере Encode обрабатывает данные несколько быстрее, чем Decode и VPP вместе, поэтому мы наблюдаем короткие простои CPU. В другом примере возможна обратная ситуация: Encode будет требовать больше времени, чем Decode и VPP, и будут наблюдаться уже простои GPU.

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

• синхронизация потоков для своевременной передачи готовой порции данных следующим по цепочке компонентам
• организация буферов между компонентами, которые позволяют продолжить работу, пока следующие по цепочке компоненты заняты
• поддержка перемещения данных между памятью CPU и GPU, чтобы аппаратный Decode мог работать с программным Encode в единой цепочке
• корректная обработка ошибок, при которых нужно останавливать весь процесс, корректировать его и возобновлять с того места, где произошла ошибка

Ни для кого не секрет, что трудно заставить правильно работать сложное приложение и требуется достаточно много ресурсов на его разработку и поддержку (поэтому тут я не привожу псевдо-код). И, конечно же, существуют способы избежать подобного дискомфорта. Ваши идеи?

Опять же, я планирую в следующей публикации предложить свой способ, «не переключайтесь»

Спасибо за внимание!

Слава.

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

Синхронная однопотоковая модель хорошо подходит для начального исследования процесса транскодирования. Её реализация предельно проста и наглядна для демонстрации обрабатывающих элементов и организации потока данных. Платой за простоту является низкое быстродействие, потому что кадры обрабатываются последовательно Decode, Video Preprocessing (VPP) и Encode. Каждый кадр проходит все три стадии от входного потока до выходного и только после этого начинается обработка следующего кадра как показано на Диаграмме 1.

Диаграмма 1: Однопотоковая обработка кадров

Приведённый ниже псевдо-код иллюстрирует реализацию рассматриваемой модели. Заметьте, каждая стадия обработки может быть хорошо оптимизирована, чтобы получить выигрыш от multi-core оборудования. Поэтому около каждого вызова организован цикл, который ждёт завершения операции, это называется синхронизацией (Sync)

while (there is data to process)
{
    do
    {   status = DecodeFrame();
        if (status ==    FatalError) return Error;
        if (status == NonFatalError) FixDecodeError(); // Error handling
    } while(status != Success); // Sync

    do
    {   status = VPPFrame();
        if (status ==    FatalError) return Error;
        if (status == NonFatalError) FixVPPError(); // Error handling
    } while(status != Success); // Sync

    do
    {   status = EncodeFrame();
        if (status ==    FatalError) return Error;
        if (status == NonFatalError) FixEncodeError(); // Error handling
    } while(status != Success); // Sync

    WriteFrame();
}

return Success;

Мы предполагаем, что платформа поддерживает аппаратное ускорение Decode и VPP, а Encode выполняется на CPU. Эта модель транскодирования теряет много вычислительных ресурсов как CPU, так и GPU, потому что Encode вынужден ждать завершения работы Decode и VPP, а Decode вынужден ждать, когда Encode завершит обработку предыдущего кадра. В лучшем случае теряется половина ресурсов как это показано на Диаграмме 2.

Диаграмма 2: Однопотоковая модель теряет значительную часть вычислительных ресурсов

Разумеется, существует множество способов, как улучшить быстродействие. Можете ли Вы предложить некоторые из них?

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

Спасибо за внимание!

Слава.

Дальнейшая обработка зависит от способа воспроизведения 3D видео. Я в своём эксперименте использовал доступные мне red-cyan цветные очки: один глаз смотрит сквозь красный светофильтр «R», другой сквозь циан «G+B». Поэтому в графическом редакторе для формирования результирующего изображения я взял «R» компоненту с одной половины кадра, а «G» и «B» с другой. Полученный кадр в два раза уже двойного исходного, не требует специальных устройств для отображения и при просмотре через соответствующие цветные очки выглядит объёмным. Аналогичным способом можно получить 3D видео при автоматической покадровой цветовой обработке.
Если в вашем распоряжении есть red-cyan очки, то можете оценить результат моих 3D фото экспериментов с домашним натюрмортом (250Kb 1457x1195 jpeg image)