8(495)909-90-01
8(964)644-46-00
pro@sio.su
Главная
Системы видеонаблюдения
Охранная сигнализация
Пожарная сигнализация
Система пожаротушения
Система контроля удаленного доступа
Оповещение и эвакуация
Контроль периметра
Система домофонии
Парковочные системы
Проектирование слаботочных сетей
Аварийный
контроль
Раздел: Документация

0 ... 110 111 112 113 114 115 116 ... 122

модели, которая вычисляет предполагаемое число бит В{ для кодирования макроблока t по следующей формуле:

где А - это число пикселов в макроблоке, а, - среднеквадратиче-ское отклонение яркости и хроматичности в остаточном макроблоке (т.е. мера вариации внутри макроблока), Qi — размер шага квантователя, а К и С — постоянные параметры модели. Для каждого макроблока выполняются следующие действия.

1.Измерить ai.

2.Вычислить Q, с помощью значений В. К, С, ст* используя вес п,. данного макроблока.

3.Закодировать макроблок.

4.Обновить параметры модели К и С, зная настоящее число кодовых бит, отвечающих данному макроблоку.

Вес rti макроблока контролирует его «важность» для субъективного восприятия изображения. Низкие значения а, говорят о том, что данный блок не столь важен при визуализации и он будет проквантован сильнее остальных макроблоков. Эти веса можно выбирать из условия минимизации изменений Q, при низких битовых скоростях, поскольку каждое изменение этого параметра вызывает отправку параметра модификации квантования DQUANT, что означает добавку лишних пяти бит к коду макроблока. Важно минимизировать число изменений Qi при кодировании одного кадра при низкой скорости, поскольку добавочные пять бит в макроблоке могут оказаться значительной добавкой. При высоких скоростях эти добавочные DQUANT не столь существенны, поэтому параметр Q можно менять чаще, не боясь увеличить общий размер кода. Такой метод контроля скорости эффективен для поддержки хорошего визуального качества при малом размере выходного буфера кодера и для удержания задержек кодирования на минимальном уровне (это важно для низкоскоростных приложений, работающих по описанному выше сценарию).

Дополнительную информацию о других стратегиях контроля скорости можно почерпнуть в [41].

(7.11)


элементарный поток (видео, аудио и т.п.)

пакетирование

пакеты PES от нескольких потоков

Мультиплекс

Транспортный поток

Рис. 7.40. Транспортный поток MPEG-2.

7.6. Транспортировка и хранение

Видеокодек редко используется изолированно от других приложений и модулей. Обычно он является частью коммуникационной системы, в которой помимо кодированного видео имеется кодированное аудио и другая связанная с ними информация. Объединенные данные сохраняются и/или передаются в комбинированных цифровых потоках. Существует много способов комбинирования (мультиплексирования), передачи и хранения кодированных мультимедийных данных. В последние годы стало очевидным, что не существует единого транспортного решения, которое подходит каждому сценарию и для любых приложений.

7.6.1. Механизмы транспортировки

Стандарты MPEG-4 и Н.264 не предписывают в принудительном порядке какие-то механизмы транспортировки кодированных видеоданных. Однако имеется несколько возможных транспортных решений в зависимости от метода передачи, к которым относятся следующие подходы.

Системы MPEG-2. Часть 1 стандарта MPEG-2 [42] описывает два метода мультиплексирования аудио, видео и связанной информации в цифровых потоках, подходящих для передачи (программные потоки или транспортные потоки). Каждый источник данных или элементарный поток (например, закодированная видео-или аудиопоследовательность) пакетируется в виде пакетированного элементарного потока PES (Paeketised Elementary Stream).


Пакеты PES от разных элементарных потоков мультиплексируются вместе для формирования программного потока (который обычно несет единственный набор данных аудио/видео, например, один телевизионный канал) или транспортного потока (который может содержать несколько каналов) (см. рис. 7.40). Транспортный поток использует коды Рида Соломона, а также схему сверточного кодирования, которые позволяют контролировать и исправлять ошибки, возникающие при передаче по ненадежным каналам. За хронометраж времени и синхронизацию отвечает специальная система временных отметок и штампов в последовательности пакетов. Поток данных MPEG-4 Visual может транспортироваться в виде элементарного потока с помощью программного или транспортного потока MPEG-2. Передача потока MPEG-4 Part 10/Н.264 по системам MPEG-2 осуществляется поправкой 3 к системам MPEG-2, которая находится в стадии стандартизации.

Тип загрузки

Порядковый номер

Временной штамп

Идентификатор

Загрузка (видеопакеты и т.п.)

Рис. 7.41. Структура пакетов RTP (упрощенно).

Протокол реального времени. RTP (Real-Time Protocol) [43] является протоколом пакетизации, который может применяться в сочетании с пользовательским датаграмным протоколом UDP (User Datagram Protocol) для передачи данных мультимедиа в реальном времени по сетям, которые работают по протоколу Интернета IP (Internet Protocol). Протокол UDP является более предпочтительным, чем протокол TCP (Transmission Control Protocol, протокол контроля передачи), для приложений реального времени, так как он обеспечивает малую латентность (задержку) при передаче данных по IP-сетям. Однако в нем нет механизма восстановления потерянных пакетов или синхронизации. Протокол RTP определяет структуру пакетов для данных реального времени (рис. 7.41), где имеется идентификатор типа (который сообщает тип использованного кодека при генерации данных), последовательный номер (необходимый для упорядочения пакетов, которые пребывают в произвольном порядке) и временной штамп (служащий для правильного представления времени при декодировании данных). Транспортировка кодированного аудио-, видеопотока по RTP вызывает пакетирование каждого элементарного потока в виде серий пакетов RTP,



0 ... 110 111 112 113 114 115 116 ... 122