Предисловие:

Данная статья знакомит с сетевой камерой, созданной на базе открытой ПЛИС, использующей открытый кодек Ogg Theora и управляемой встроенной ОС Linux. Автор, Андрей Филиппов, утверждает, что эта первая сетевая камера, которая совмещает высокое разрешение и высокую частоту кадров с низким объемом передаваемых данных.

Введение

Большинство сетевых камер Elphel было впервые представлено широкой публике на страницах онлайнового издания LinuxDevices.com и новая модель 333 продолжает эту хорошую традицию. Но для начала немного истории. Первой была обнародована модель 303 — высокоскоростная камера со стробируемым усилителем яркости, которая работала под управлением встроенной ОС Linux и базировалась на процессоре ETRAX100LX шведской компании Axis Communications AB. Во второй (Elphel-313) благодаря использованию реконфигурируемой ПЛИС¹ (Spartan-2e производства компании Xilinx, 300 тыс. вентилей) была значительно улучшена производительность, что позволило осуществлять сжатие изображений формата JPEG размером 1280x1024 пикселей со скоростью 15 кадров/сек. Эта скорость была в дальнейшем увеличена до 22 кадров/сек., одновременно была добавлена поддержка сенсоров Micron более высокого разрешения — 1600x1200 и 2048x1536. Аппаратные решения на основе ПЛИС обеспечивают высокую степень универсальности, благодаря чему те же самые системные платы, что используются в 313-х камерах, без изменений стали применяться и в камере модели 323, которая обладает значительными конструкционными отличиями: в этой камере установлена огромная (36мм x 24мм) ПЗС² матрица Kodak KAI-11000 с разрешением 4004 x 2672 пикселя, оборудованная электронным затвором.

Что должна уметь делать идеальная сетевая камера?

Наиболее массовое распространение сетевые камеры получили в системах охранного видеонаблюдения. Для того, чтобы вытеснить традиционные системы, построенные на базе аналоговых видеокамер, их цифровые аналоги должны обладать достаточно высоким разрешением, позволяющим отказаться от использования поворотно-наклонных платформ (PTZ), обладающих одним существенным недостатком: объектив камеры может легко пропустить важное событие просто потому, что в нужный момент он был направлен в другую сторону. Но цифровые камеры, которые совмещают высокое разрешение с высокой частотой кадров, выдают огромные потоки данных и всего несколько камер могут исчерпать пропускную способность сети, а, кроме того, требуют слишком объёмных накопителей для архивации отснятого материала. Однако, эта проблема свойственна только камерам, использующим для сжатия выходных данных алгоритм JPEG/MJPEG: настоящая видеокомпрессия может дать гораздо лучшие результаты. Таким образом, идеальная сетевая камера должна обладать тремя важными качествами — высоким разрешением, высокой частотой кадров и при этом низким объемом передаваемых данных.

До настоящего времени ни одна сетевая камера не имела всех трех качеств одновременно. Некоторые обеспечивают хорошую компрессию (например, MPEG-4) при высокой частоте кадров, но обладают низким разрешением. Другие совмещают высокое разрешение с высокой частотой кадров (к ним относится, в частности, ранняя модель Elphel 313), но объем передаваемых данных слишком высок. Это объясняется тем, что видеосжатие высокого разрешения в режиме реального времени — непростая задача и требует значительных вычислительных ресурсов.

ПЛИС, которая может справиться с задачей

Ресурсы ПЛИС в камере модели 313 уже использованы на 98%, что препятствует дальнейшему добавлению новых функциональных возможностей. Однако, за время, прошедшее со времени создания той ранней модели, технологии не топтались на месте и сегодня существуют более мощные микросхемы, способные помочь в решении многих проблем. В частности, в 333-й камере используются уже ПЛИС Xilinx Spartan 3 (объемом в миллион вентилей), которые в три раза больше, значительно быстрее и имеют дополнительные весьма полезные узлы в виде встроенных умножителей и блоков ввода/вывода, поддерживающих работу с DDR памятью. И все это технологическое богатство умещается в таком же компактном корпусе FT256, как и у предыдущей модели Spartan.

Как только в бесплатном ПО Xilinx (я надеюсь, что когда-нибудь они будут выпускать именно свободное, а не просто бесплатное программное обеспечение) появилась поддержка этих ПЛИС, я был готов приступить к созданию новой модели камеры. Поддержка ПЛИС именно бесплатными средствами разработки очень важна для нашей продукции, так как все камеры Elphel поставляются с исходными кодами используемого ПО (включая программы в ПЛИС, написанные на Verilog HDL³), распространяемого под лицензией GNU/GPL. Мы стараемся сделать так, чтобы обладатели камер Elphel имели возможность свободно изменять (и улучшать) код используемых в наших устройствах программ.

Детали аппаратной реализации

Конструкция Elphel-333 во многом основана не предыдущей модели: в камере использован тот же самый процессор, при этом удалось сохранить практически без изменений даже всю центральную часть печатной платы, где он соединяется с памятью (ОЗУ⁴ и флэш). С другой стороны, вдобавок к использованию более мощной ПЛИС, в новой камере увеличены объемы памяти: флэш выросла до 16МБ (против 8МБ), а системное ОЗУ — до 32МБ (взамен 16МБ). Память, подключенная непосредственно к ПЛИС, тоже удвоена, а плюс к этому одновременно удалось более чем вдвое увеличить ее скорость за счёт перехода на использование более современной DDR SDRAM⁵. Роль памяти, подключенной к ПЛИС, очень важна для видеосжатия, т.к. вся информация на своем пути от приемника изображений до выхода с компрессора проходит через эту память три раза.

Несмотря на эти кардинальные усовершенствования, размер системной платы остался прежним. Более того, мне даже удалось ее немного «ужать»: сохранив уже привычные габаритные размеры 38мм х 89мм (3,5 дюйма х 1,5 дюйма), я изменил форму системной платы, в результате чего пространственное расположение её дальних углов внутри корпуса камеры (около разъема локальной сети) позволило осуществить установку герметизированных разъемов. В дальнейшем это будет способствовать пригодности камеры для наружной установки без использования дополнительного громоздкого защитного кожуха.

Выбор подходящего для камеры кодека

Вплотную занимаясь разработкой аппаратной части камеры, я пока не стал разбираться с собственно алгоритмами видеокомпрессии, предположив лишь, что что-нибудь вроде p-frames формата MPEG-2 должно сильно улучшить степень сжатия для стационарно установленных камер, у которых большую часть площади кадра обычно занимает неподвижный фон. Следующий же уровень эффективности видеосжатия, когда изображение разбивается на участки, для каждого из которых независимо указывается оптимальное смещение от опорного кадра (motion vectors), требует более высокой полосы пропускания доступа к памяти. Благодаря усовершенствованию аппаратной части камеры данная проблема стала менее актуальной, поэтому я решил пока не заниматься реализацией этого механизма, а оставить его для будущих усовершенствований.

Итак, к августу 2004 года у меня было протестировано "железо" опытного экземпляра новой камеры и для начала я перенес на неё (минимально адаптировав код к новому типу ПЛИС и DDR памяти) программное обеспечение от предыдущей модели, позволяющее работать с форматом MJPEG. И сразу же легко получил значительный выигрыш в «скорострельности» — для кадра с разрешением 1280х1024 камера легко выдала 30 кадров/сек (максимальную для сенсора) вместо 22 кадров/сек у модели 313. Тогда для продолжения работы я заказал себе в одном из онлайновых магазинов книгу с описанием деталей реализации стандарта MPEG-2. И только там я обнаружил информацию, что этот стандарт, в отличие от JPEG/MJPEG, требует лицензирования. Лицензионные отчисления невелики, особенно если сравнивать со стоимостью самой камеры, но, будучи принципиальным противником самой идеи патентов на программное обеспечение, я не хотел поддерживать ее материально.

Это означало, что мне нужно было искать альтернативный кодек. К счастью, поиски не отняли много времени, т.к. вскоре я нашел решение, оказавшееся лучшим и с технической, и с юридической точек зрения. Заменой несвободного «коллеги» стал кодек Theora, разработанный Фондом Xiph.org.. Его алгоритм основан на коде свободного кодека VP3, созданного компанией On2 Technologies и распространяемого под лицензией, позволяющей пользоваться им на безвозвратной основе (т.е. бесплатно) и не требующей каких-либо патентных отчислений за использование как самого VP3, так и производных от него кодеков. Theora — это высокоэффективный видеокодек, составляющий реальную конкуренцию формату MPEG-4 и другим технологиям видеосжатия, использующим узкую полосу канала передачи данных.

Реализация видео-кодера Theora на ПЛИС

К этому моменту у меня были как работающее "железо", так и документация по выбранному формату. Кстати, качество документации оказалось довольно высоким. Могу сказать это вполне определённо, ведь я стал первым, кто реализовал данный формат «с нуля» — только по документации, а не модифицируя уже существующий код. И лишь в одном месте мне встретилась ошибка, где документация разошлась с реальным кодом.

Но даже со всеми упрощениями, которые я выбрал для камеры (кодер, в отличие от декодера, не обязан включать в себя поддержку всех возможностей формата), задача стояла достаточно сложная. Я временно отказался от поддержки компенсации движения (motion vectors) и использования фильтра, сглаживающего границы между блоками 8х8 пикселей, заметные при высокой степени сжатия (loop filter). Результат оказался малоутешительным: при включенном режиме компенсации разброса чувствительности начального уровня пикселей (FPN⁶), требуемая средняя скорость обмена данными с памятью составляла около 95 процентов пиковой полосы пропускания используемой микросхемы (500МБ/сек при тактовой частоте в 125МГц). Для каждого кодируемого пикселя память должна была:

• Выдать данные для коррекции FPN (2 байта)


• Получить скорректированные данные сенсора и записать их в построчном порядке (1 байт)


• Обеспечить данные для преобразователя цветового пространства после матрицы светофильтров (Bayer) в формат YCbCr 4:2:0, который требуется для компрессора. Данные из памяти поступают в виде перекрывающихся плиток 20х20 пикселей для каждого макроблока 16х16 пикселей, чтобы при интерполяции не возникало артефактов на границах макроблоков. Таким образом, на каждый пиксель приходится (20х20)/(16х16) ~ 1,56 байта


• Для кадров типа INTER (разностных) требуется считывание опорного кадра из памяти и для всех кадров (и INTER, и INTRA — ключевых) требуется запись опорных кадров в память. Это дает еще 2 х 1,5 = 3  (коэффициент полтора возникает потому, что в кодировке YCbCr 4:2:0 для каждых 4 пикселей сенсора вычисляются 4 яркостных пикселя(Y) и по одному на каждую цветовую компоненту (Cb и Cr), т.е. всего шесть.

И это еще не все. В формате Theora, в противоположность, например, JPEG, квантизованные коэффициенты ДКП⁷ (DCT) переупорядочиваются глобально по кадру: это уменьшает энтропию и дает дополнительной выигрыш в сжатии. Первыми в выходной поток поступают все DC коэффициенты (средние значения для блоков из 8х8 пикселей) — сначала яркостные (luma – Y), а потом цветоразностные (chroma — Cb и Cr). Затем все повторяется и для оставшихся 63-х AC коэффициентов — они выдаются, начиная с самых низких пространственных частот (AC1) и заканчивая самыми высокими (AC63). А так как сам двумерный ДКП выдает сразу все 64 коэффициента (DC, AC1..AC63) одновременно для каждого блока, то набор коэффициентов для всего кадра приходится временно сохранять в памяти. Учитывая, что для каждого коэффициента требуется 12 бит, получаем еще 2 х 1,5 х (12/8) = 4,5 байта, требующих передачи.

Всего получается 12,11 байт передачи для каждого пикселя. При разрешении 1280x1024 и частоте в 30 кадров/сек средняя скорость поступления пикселей составляет 39,3 Мпикс/сек и требуемая полоса пропускания канала памяти составляет 476 МБ/сек. Следовательно, теоретически для памяти с пиковой пропускной способностью 500МБ/сек успеть можно, однако обычно такая высокая эффективность использования циклов доступа к памяти достигается в тех случаях, когда доступ осуществляется последовательно и порядок считывания совпадает с порядком записи данных. При таком варианте легко «спрятать» операции активации (activate) и освобождения (precharge) банков, осуществляя их одновременно с передачей данных из/в активный в данный момент банк.

В нашем случае задача более сложная, особенно при записи и чтении квантизованных коэффициентов ДКП, представляемых как 12-ти битные токены, т.к. последовательности записи и чтения в значительной степени "ортогональны" друг другу, таким образом данные, которые были близки друг к другу при записи, оказываются очень далеки при чтении и наоборот. "Очень далеки" в данном случае означает то, что они оказываются разнесены по времени дальше, чем может быть буферизовано во встроенной внутренней памяти ПЛИС (всего в микросхеме встроено 24 блока по 2 килобайта).

Все это вместе сделало разработку контроллера памяти одной из самых сложных задач проекта. Хотя, на самом деле, это именно такая задача, где ПЛИС обеспечивает высокую эффективность по сравнению с универсальными контроллерами DDR SDRAM, так как довольно сложные структуры данных могут быть "скомпилированы" прямо в "железо".

Когда код восьмиканального контроллера квази-одновременного доступа к микросхеме DDR SDRAM был написан и просимулирован, решить остальные задачи стало намного проще. Преобразователь цветового пространства (из Bayer в YCbCr 4:2:0) был временно использован от предыдущей разработки, алгоритмы прямого и обратного двумерного дискретного косинусоидального преобразования (ДКП) были реализованы в точности, как требовалось по стандарту Theora. Каждая из двух стадий каждого из двух преобразователей использует встроенный в ПЛИС умножитель, работающий на удвоенной пиксельной частоте пространства YCbCr, что сейчас составляет 125МГц, таким образом всего на реализацию преобразователей потребовалось 4 умножителя. Квантизатор и деквантизатор коэффициентов вместе используют встроенный блок памяти для хранения таблиц множителей, заранее заполняемых программным обеспечением согласно спецификациям кодека.

Модуль предсказания постоянной составляющей (DC prediction) использует информацию от предыдущих блоков для вычисления ожидаемого значения DC компоненты текущего блока, при этом кодируется разница между истинным и ожидаемым значениями. В модуле используется блок встроенной памяти ПЛИС для хранения информации о блоках предыдущего ряда, его размер позволяет работать с кадрами шириной до 4096 пикселей. Обработанные DC компоненты потом буферизуются вместе с AC компонентами, а затем в обратной зиг-заг последовательности (AC63..AC1, DC) поступают в модуль, выделяющий последовательности нулей и подготавливающий 12-битные токены для записи в память.

Когда запись токенов для целого кадра заканчивается, запускается вторая ступень компрессора (а вышеописанная первая часть, тем временем, подготавливает токены следующего получаемого кадра). Теперь токены считываются их памяти в последовательности, соответствующей выходному потоку в «кодированной» последовательности. Самый наружный цикл перебирает номера коэффициентов ДКП — начиная с постоянной составляющей и переходя ко все более высоким пространственным частотам. Для каждого коэффициента перебираются все цветовые слои (всего их три: Y, Cb и Cr). Для каждого слоя идет перебор по суперблокам размером 32х32 пикселя в сканирующей последовательности: в каждой строке слева направо, а сами строки – снизу вверх. Внутри каждого суперблока помещается 16 блоков (8х8 пикселей каждый), каждый из которых в каждом проходе дает один токен (который может быть пропущен), и эти блоки обходятся в Гильбертовой последовательности, которая для размера 4х4 выглядит как заглавная греческая буква омега со вдавленной складкой на верхушке.

Когда токены упорядочены подобным образом, то довольно часто встречается ситуация, когда, начиная с определенного индекса, для нескольких блоков подряд все коэффициенты нулевые. В таком случае число таких блоков подсчитывается и они кодируются одним токеном (EOB run). Такие токены не могли быть выделены на первой ступени компрессора, т.к. тогда обработка соседних в кодированной последовательности блоков была сильно разнесена по времени.

Теперь все токены (как считанные из памяти [coefficient tokens], так и вычисленные для последовательности закончившихся блоков [EOB runs]) кодируются в последовательности переменной длины с помощью набора таблиц кодов Хаффмена. Различные таблицы используются для различных цветовых слоев и различных групп индексов ДКП. Полученные таким образом последовательности битов переменной длины соединяются вместе, разбиваются по 16 бит и поступают в выходной буфер. А уже оттуда по 32-битному каналу прямого доступа к памяти (DMA) передаются в системную память, непосредственно доступную процессору.

Результаты, благодарности и планы

К настоящему моменту написано начальное программное обеспечение для камеры, которое позволило обнаружить и исправить наиболее очевидные ошибки в коде ПЛИС, реализующем часть алгоритмов видеокомпрессии Theora. Камера успешно протестирована с сенсором с разрешением 1280х1024 пикселей на скорости 30кадров/сек (камера может также работать с сенсорами 2048х1536 при скорости 12 кадров/сек и поддерживать будущие сенсоры разрешением до 4.5 мегапикселей).

Основное назначение уже разработанного ПО камеры — служить тестовым стендом для проверки аппаратного видеокомпрессора. В камере пока еще нет видеостримера — короткие (до 18МБ) видеоклипы поступают в системную память камеры, а затем программно инкапсулируются в формат Ogg (полученные от ПЛИС видеоданные разбиваются на страницы, к ним добавляются заголовки и вычисляются контрольные суммы). Но я не думаю, что разработка видеостримера займет много времени: у нас есть команда программистов, появившаяся около года назад в результате конкурса на разработку видеостримера для предыдущей модели камеры (с возможностями JPEG/MJPEG), проведённого компанией Elphel совместно с российским онлайн-изданием Компьютерра. Благодаря этим усилиям у модели 313 теперь есть 7 альтернативных стримеров, некоторые из которых способны работать со скоростью (ограниченной ПЛИС) в 22 кадра/сек для разрешения 1280х1024 и пересылать данные со скоростью до 70Мб/сек (такие потоки требуются только при установках очень высокого качества JPEG).

Победитель конкурса — Александр Меличенко (Киев, Украина) разработал первую версию своего стримера еще до того, как получил от нас камеру. Ему оказалось вполне достаточно доступа к онлайн камере, установленной в компании Elphel (штат Юта, США), используя лишь протоколы telnet и ftp, чтобы дистанционно установить, запустить и отладить свое приложение под операционной системой GNU/Linux, управляющей процессором, с которым Александру никогда раньше не приходилось иметь дела (Axis Communications ETRAX 100LX).

Сергей Хлутчин (Самара, Россия) доработал дистрибутив GNU/Linux Knoppix (Live CD), что позволило тем из наших пользователей, которые обычно работают в другой операционной системе, раскрыть полные возможности наших камер. Видеоплеер Apple QuickTime хорошо воспроизводит RTP/RTSP видеопоток, нагруженный MJPEG, но мы никак не смогли отключить трехсекундную задержку на буферизацию, встроенную в этот проприетарный продукт: поэтому, например, настраивать камеру в режиме реального времени (отслеживая производимые изменения на дисплее) с ним не очень удобно. Выбор GNU/Linux в качестве управляющей операционной системы был сделан по лицензионным соображениям, но также свою роль сыграло и то обстоятельство, что используемый для воспроизведения видеопотока Mplayer (работающий, конечно, не только под GNU/Linux) в «родной» системе чувствует себя гораздо лучше.

Именно в этом направлении Elphel планирует двигаться и дальше. Мы не будем ждать того времени, когда большинство наших клиентов будут использовать свободные операционные системы на своих десктопах. Благодаря Клаусу Кнопперу (автору Knoppix Live-CD) мы можем включать операционную систему в комплект поставки с каждым нашим продуктом, так будет и с новой камерой модели 333 — первой сетевой камерой, которая совмещает высокое разрешение и высокую частоту кадров с низким объемом передаваемых данных. И выдает видеоданные в формате Ogg Theora.

Послесловие

Согласно А. Филиппову, высокое разрешение вместе с высокой частотой кадров представляет (по крайней мере в настоящее время) сложности в нахождении достаточно мощного компьютера, чтобы декодировать и отображать видеопоток с той скоростью, с которой его выдает камера. Филиппов попросил читателей LinuxDevices, у которых есть доступ к быстрым компьютерам (таким, как системы с двумя процессорами Xeon 3,6 МГц), загрузить образцы клипов и рассказать о своих успехах автору данной статьи.В ближайшее время Андрей планирует демонстрировать камеру на различных специализированных выставках и хотел бы опытным путём узнать, насколько быстрый компьютер ему для этого потребуется.

1. ПЛИС — программируемая логическая интегральная схема. Аналог англ. аббревиатуры FPGA — Field Programmable Gate Array
2. ПЗС — прибор с зарядовой связью. Аналог англ. аббревиатуры CCD — Charge Coupled Device
3. HDL — Hardware Description Language, язык описания цифровой аппаратуры.
4. ОЗУ — оперативное запоминающее устройство.
5. DDR SDRAM — синхронная память с двойной скоростью передачи данных.
6. FPN — fixed-pattern noice, шум неподвижного образца.
7. ДКП — дискретное косинусоидальное преобразование, от англ. аббревиатуры DCT — discrete cosine transform.

Об авторе: Андрей Николаевич Филиппов страстно увлечен применением современных технологий для встраиваемых компьютерных устройств, особенно в области ввода и обработки изображений. У него более двадцати лет опыта исследований и разработок в области высокоскоростных аналогово-цифровых систем, программируемых микросхем, микропроцессорных устройств и их программного обеспечения, в том числе для ввода и обработки изображений в лазерной физике и автоматизации научных исследований. У Андрея Николаевича ученая степень кандидата физ.-мат. наук (Ph.D.), полученная в Московском физико-техническом институте. Фото автора сделано высокоскоростной камерой с усилителем яркости.

Related Stories: