Мы — команда
Наш первый совместный проект состоялся в 2006 году. Именно он собрал нас, отдельных разработчиков-фрилансеров, работников КБ и просто инженеров, в одну команду, способную решать сложные задачи сообща.
Задача
Задача, которая нас объединила, сегодня может показаться несложной. Это была часть проекта, связанного с видеокодированием. Только набирающий на тот момент популярность стандарт видеосжатия H.264 был знаком лишь узкому кругу специалистов в данной области. Он еще не получил такого широкого применения, как сейчас — от телевидения высокой четкости до смартфонов и видеорегистраторов. Производители «Систем на Кристалле» тогда еще не встраивали аппаратные ускорители H.264 в каждый свой чип. А вычислительной мощности персональных компьютеров еще не было достаточно, чтобы программно осуществлять хотя бы воспроизведение такого видео.
Сейчас задача декодирования видео по стандарту H.264 реализуется повсеместно. Но будет большим заблуждением считать эту задачу простой. Без той массы наработок в виде аппаратных ускорителей и программных библиотек, существующих на сегодняшний день, кодирование/декодирование видео по стандарту H.264 всегда будет алгоритмически сложной задачей.
Наш проект делался на заказ для компании, которая специализируется на выпуске программных модулей видео обработки, так называемых «IP core». Несмотря на успешность компании в этой области, потребность рынка в аппаратных решениях не могла быть не замечена ее руководством. Ими было принято решение об открытии нового направления разработок — аппаратных модулей видео обработки, так называемых «Hardware IP core». Быстро набранная заказчиком команда специалистов принялась за исследование новой области. И спустя некоторое время сделала вывод о масштабности и нетривиальности аппаратного решения задачи.
Так как направление для компании было все-таки непрофильным, а ресурсы требовались немалые, решение об аутсорсинге напрашивалось само собой. В результате к работе над проектом была привлечена наша команда.
Начать было решено с наиболее функционально законченного и востребованного в процессе как кодирования, так и декодирования модуля постобработки — Deblocking Filter. Требовалось аппаратно реализовать функцию Deblocking Filter для режима High Profile на уровне 4.2 в режиме реального времени. Это соответствует профессиональному (студийному) качеству кодирования изображения высокой четкости.
О стандарте
Для тех, кто мало знаком с внутренностями H.264, напомним: изображение кодируется блоками размером 16×16 пикселов – так называемыми макроблоками. В процессе обработки макроблоки разбиваются на еще более мелкие блоки размером 4×4 пиксела. При малой скорости канала передачи данных и низком качестве кодирования вы можете видеть эти квадраты во время воспроизведения.
Важно, чтобы при «склейке» изображения из этих квадратов не было резких переходов от блока к блоку, иначе будет видна «сетка». Во избежание этого, после декодирования необходимо произвести сглаживающую фильтрацию: сначала вертикальных границ между блоками, а потом горизонтальных.
Перед вами пример работы функции:
Мы видим, что после обработки изображения функцией Deblocking Filter на нем нет цветовых скачков и глазу почти незаметно, что кодировались не связанные друг с другом блоки.
Поиски решения
Мы постепенно нащупывали пути решения. Найти его, хотя бы в полуготовом виде, в Интернете не удалось. К сожалению, ни Sony, ни Samsung, ни все остальные компании, реализовавшие данный стандарт, ничего об этом не пишут: ни в открытом доступе, ни в научных журналах. Все, что мы нашли, было сырым и пригодным только для первичной оценки и выбора подхода, но не более того.
Изучение описания стандарта H.264 заняло немало времени. Детальное чтение этого текста, напоминающего смесь математики и специально запутанного плана побега из тюрьмы, принесло свои плоды: было сформировано четкое понимание того, как считаются интерполяции, какие данные при этом участвуют и в какой последовательности.
Реализация
Во всех рассмотренных нами подходах реализовывалась лишь часть требуемого функционала. Выбрав наиболее удачный, на наш взгляд, подход, мы принялись на его основе создавать собственное решение, которое позволило бы удовлетворить предъявляемые требования в полной мере. Нужно было учитывать, что целевая область применения – профессиональная, а значит, в рамках заданного режима работы должны поддерживаться все без исключения возможности, заложенные в стандарте. Включая, например, экзотичный вариант сканирования – MBAFF (Macroblock-Adaptive Frame-Field Coding), в котором макроблоки объединяются в пары, и каждая из них кодируется либо с прогрессивной разверткой, либо с чересстрочной.
Оптимальное решение пришло не сразу. Последовательность обработки и архитектура исполнительного устройства многократно видоизменялись. Несколько раз, когда уже казалось, что решение найдено, приходилось отказываться от него и начинать все заново. Ведь многие нюансы всплывают не сразу: решение может хорошо подходить для работы в одном режиме и быть безнадежным в другом. Но раз от раза мы все ближе подбирались к оптимальному решению. И, наконец, нашли долгожданный компромисс между объемом аппаратуры, ее сложностью и способностью выполнять все функции.
Тестирование
Каким бы удачным ни было придуманное решение, конечный результат всегда определяется методикой и качеством системы тестирования. При таком сложном и витиеватом алгоритме обработки, как в H.264, создать безошибочное тестовое окружение – отдельная непростая задача. К счастью, это очевидно и для самих разработчиков стандарта, поэтому к нему прилагается эталонный код на Си, реализующий описываемые стандартом функции.
Зачем же нужно разрабатывать программные реализации кодеков, если код на Си уже идет вместе со стандартом? Дело в том, что данный код абсолютно не подходит для практического применения. Он намеренно повторяет все шаги, описанные в стандарте, только не на английском, а на Си. Единственное предназначение кода — являться эталоном правильности функционирования.
Как же быть с аппаратурой, ведь она описывается не на Си? Или на Си тоже? Да, и на Си тоже. А точнее на SystemC – диалекте, специально разработанном для описания аппаратуры на языке Си. SystemC позволил нам интегрировать Reference Code стандарта непосредственно в тело тестового окружения (Test Bench Environment) без каких-либо адаптаций. Это полностью исключило вероятность внесения ошибок в код. Помимо прочего такой подход к тестированию дал возможность осуществлять проверку части промежуточных данных на этапе работы устройства, а не только сравнивать выходные данные с эталонными. Это позволило значительно ускорить процесс отладки разрабатываемого кода.
Оптимизация
Для успешного решения задачи требовалось конвейеризировать работу функции интерполяции коэффициентов цветовых компонентов. В процессе поиска оптимального баланса в распределении логики по этапам конвейера был сделан важный и глобальный по своей сути вывод. В описании аппаратуры нужно всегда придерживаться принципа исключения лишних ограничений, все описываемые ограничения должны быть минимальны и диктоваться только сутью задачи. Дело в том, что алгоритму оптимизации, заложенному в средства синтеза (RTL Synthesis Software), требуется «свобода действий». Излишние ограничения делают его работу неэффективной и могут загубить весь потенциал предложенного разработчиком решения.
Следуя данному принципу, нам удалось получить код, синтез которого позволял с запасом достичь необходимых частот работы. Это обрадовало заказчика, а мы получили первый опыт совместной работы.
Технические характеристики разработанного продукта
- полное соответствие требованиям стандарта ISO/IEC 14496‑10 (H.264/MPEG-4 Part 10), High Profile, Level 4.2
- поддержка всех режимов сканирования: Frame, Field и MBAFF
- скорость обработки — до 500 000 макроблоков в секунду (более 60 кадров в секунду FullHD (1080p) разрешения)
- поддержка режима цветности 4:2:0
Реализация в ПЛИС
| Конфигурация | Технология | Занимаемый объем *1 | |
Slices *2 | BRAM | ||
| Поддержка Frame/Field, поддержка MBAFF | Xilinx Spartan-3x | 1515 | 13 |
| Xilinx Virtex-4 | 1522 | 13 | |
| Xilinx Virtex-5 | 534 *3 | 13 | |
*1 Приведенные данные являются приблизительными и служат для предварительной оценки.
*2 Фактическое количество используемых слайсов зависит от процентного соотношения несвязанной логики.
*3 Слайсы Virtex-5 содержат в 2 раза больше LUTs (Look Up Tables), чем предшественники.
Использованные технологии
Проектирование ПЛИС
Целевая технология:
- Xilinx Spartan-3x
- Xilinx Virtex-4
- Xilinx Virtex-5
Языки описания аппаратуры:
- VHDL
- SystemC
Алгоритмы обработки данных:
- H.264, High Profile, Level 4.2
Методики и технологии верификации:
- задание правил соответствия (assertion-based verification)
- моделирование отдельных составных узлов (block-level simulation)
- использование эталонной модели (golden model based methodology)
Впоследствии мы реализовали еще несколько проектов по обработке видео потоков.
Но этот «пилотный» проект запомнился нам больше других. Его инновационность и смелость решений вдохновляет нас до сих пор.