Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Ваш интернет-бизнес" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
| ← Февраль 2005 → | ||||||
|
1
|
2
|
3
|
5
|
6
|
||
|---|---|---|---|---|---|---|
|
7
|
8
|
9
|
10
|
11
|
12
|
13
|
|
14
|
15
|
16
|
17
|
18
|
19
|
20
|
|
21
|
22
|
23
|
24
|
25
|
26
|
27
|
|
28
|
||||||
Статистика
0 за неделю
Статьи по электронике
| Информационный Канал Subscribe.Ru |
Статьи по электронике
Автор рассылки: Вячеслав Кулаков
Сайт рассылки
Приветствую Вас после более чем годового перерыва, вызванного отсутствием времени у автора рассылки. К сожалению, из-за ведения сразу нескольких больших проектов возможности писать статьи и вести рассылку практически не было. Однако, в большинстве своем эти проекты уже завершены, и в связи с этим появилась возможность предложить Вашему вниманию еще один цикл статей по очень интересной на взгляд автора теме – сжатию видео изображений. Эта тема представляется актуальной, т.к.
мы все практически ежедневно пользуемся сжатым видеосигналом (фильмы, цифровые видеокамеры, видеонаблюдение и т.д.), однако информации о том, как это все работает, на русском языке крайне мало.
Стоит отметить, что сама по себе тема сжатия видеоизображения очень объемна и включает в себя множество других тем. Поэтому в нескольких статьях охватить все аспекты сжатия видео невозможно. Однако автор постарается достаточно подробно рассказать об основных подходах к решению вопросов сжатия и дать информацию, необходимую для самостоятельной разработки простого видео кодера/декодера. Стоит сразу оговориться, что слово «простого» не означает простоту программной реализации.
Разработка кодера «с нуля» даже с самыми минимальными требованиями займет несколько месяцев ежедневной работы.
Прежде чем начать говорить конкретно о сжатии, желательно прежде обозначить систему, применительно к которой будет производиться сжатие видеосигнала. Ниже на рис.1 приведен пример типичного кодера видеоизображения.
Как видно из рисунка, в данном примере вся обработка видео изображения производится в цифровом процессоре (DSP). Разумеется, это можно делать и на чем-либо другом, например, на компьютере, однако, применение DSP автору представляется наиболее интересным и перспективным, особенно в связи с появлением в последнее время новых относительно недорогих цифровых процессоров, основной задачей которых является обработка изображений. Однако, автор в данном цикле статей не будет привязываться
к конкретному типу процессора, а читателю не обязательно иметь знания по DSP. Отсутствие знакомства с DSP не будет служить помехой пониманию излагаемого материала.
Видео изображение в приведенном примере поступает в DSP с кодека, который оцифровывает аналоговый видеосигнал и преобразует его цифровую форму со стандартным интерфейсом ITU - 656. В цифровом потоке этого интерфейса уже разделены составляющие яркости и цвета, а также выделены синхросигналы. Все это сделано для того, что бы программист мог по своему желанию получать ту часть видеосигнала, которая ему нужна. Разумеется, вместо аналоговой камеры и кодека можно применять цифровую
камеру.
Как известно, видеосигнал может иметь как прогрессивную развертку, так и чересстрочную. В первом случае видеоизображение состоит из последовательности сменяющих друг друга кадров. Во втором, каждый кадр состоит из двух полей с чередующимися строками. Цифровая обработка изображения в процессоре производится покадрово. Поэтому в случае прогрессивной развертки для обработки загружается кадр, а в случае чересстрочной – поле. При обработке видео с чересстрочной разверткой из двух
полей сделать один кадр простым их объединением не получится, т.к. при этом движущиеся объекты будут «размазанными» вследствие их движения не от кадра к кадру, а от поля к полю. Таким образом, для сжатия видео, его необходимо загружать в адресное пространство процессора в виде кадров или полей. Т.к. работа с полями несколько усложняет алгоритм обработки, далее будет идти речь о покадровом сжатии видео. Принципиально при этом ничего не изменится. К примеру, можно считать, что из кодека в адресное пространство
процессора загружается каждое первое поле кадра, а второе поле игнорируется.
Так же стоит отметить, что какой бы DSP не использовался, его внутреннее ОЗУ значительно меньше, чем требуемая память для сохранения одного (а в действительности одновременно необходимо хранить больше одного) кадра. Например, черно-белое 8-ми битное изображение размером 352 x 288 будет занимать 101376 байт. Поэтому изначально получаемый кадр загружается во внешнее ОЗУ (обычно SDRAM), а далее блоки изображения перегружаются для обработки во внутреннее ОЗУ, которое имеет значительно
более высокое быстродействие. Все пересылки данных в основном выполняются через прямой доступ к памяти (DMA), что позволяет вести их в фоновом режиме.
Для примера рассмотрим оцифровку сигнала стандарта PAL. Всего в этом сигнале в каждом кадре содержится 625 строк (по 312,5 в поле) и передается 50 полей в секунду.
При этом после оцифровки в каждом поле останется 288 строк (так называемое активное видео), остальные строки приходятся на кадровую синхронизацию. Если второе поле кадра не требуется, то получится, что видео будет состоять из 25 кадров в секунду размером 288 на 1440 байт. Если не требуется цветовая составляющая, ее можно отбросить, что уменьшит размер кадра до 288 на 720 байт. При этом изображение получится растянутым в стороны. Чтобы привести размер кадра к обычному размеру,
из имеющихся 720 байт можно взять каждый второй, в результате чего его размер уменьшится до 288 на 360 байт. И последнее, что нужно сделать – это сделать размер кадра кратным 16 (зачем – будет видно дальше), откинув в начале и в конце строки по четыре байта. В результате получим окончательный размер кадра – 288 на 352 байта. Эти байты обычно размещаются в ОЗУ процессора в виде массива последовательно загруженных строк.
Таким образом, в простейшем случае из обычного PAL - сигнала можно получить черно-белое видео, состоящее из последовательности кадров с частотой до 25 кадров/сек., размером 288 на 352 пикселя.
Стоит отметить, что для алгоритмов сжатия размер кадра значения не имеет, важно лишь, чтобы он был кратен 16. Он только лишь влияет на плотность выходного потока и время работы кодера/декодера, сами алгоритмы при этом не меняются.
http://subscribe.ru/
http://subscribe.ru/feedback/Подписан адрес:
Код этой рассылки: tech.electronic1Отписаться
| В избранное | ||
