Дискретное косинусоидальное преобразование

Для описания и передачи данных алгоритм сжатия может использовать уравнение вместо многократной выборки фактических значений. Пред­положим, Вы хотите нарисовать прямую линию. Элементарная алгебра учит нас, что прямую задает уравнение у =mx+C. Это означает, что линию можно «сжать» до всего лишь двух значений — m и С.

Разумеется, компрессия вовсе не так проста. Сложность составляет динамическое построение уравнения, описывающего вызвавшие инте­рес данные. Это уравнение обычно значительно сложнее, чем уравне­ние прямой линии. Одна из методик сжатия видеоданных — дискретное косинусоидальное преобразование (discrete cosine transform, DCT). Здесь данные представлены в виде ряда косинусоид. Сохраняются лишь некоторые из них (соответствующие основным частотам), но при этом происходит потеря части данных.

DСТ используется п стандартах MPEG (Moving Picture Experts Group). DCT относится к методам внутрикадрового кодирования, поскольку в конкретный момент времени приме­няется к одному кадру.

 

Протоколы мультимедиа

Для передачи мультимедиа через Интернет создано множество прото­колов. Все они находятся на различных стадиях утверждения.

МВоnе

Магистраль группового вещания (Multicast backbone, МВоnе) — сеть, которая существует внутри Интернета с начала 1992 года. МВоne состо­ит из IP-адресов класса D и набора маршрутизаторов, поддерживаю­щих групповое вещание протокола IP. Многие маршрутизаторы в МВоnе выполняют протоколы IP-маршрутизации, обеспечивающие групповое вещание. Некоторые из них — на самом деле обычные рабочие стан­ции, выполняющие роль маршрутизаторов. Другие — коммерческие маршрутизаторы с модифицированным ПО, Когда IP-пакеты, адресо­ванные группе получателей, необходимо переправить через те участки Интернета, которые не поддерживают групповое вещание протокола IP, то используется «туннелинг». То есть IP-пакеты, адресованные группе получателей, вкла­дываются в обычные IP-пакеты, адресованные маршрутизатору на дру­гом конце туннеля (рис. 3).

МВоne применяют для тестирования новых протоколов маршрутизации, ПО группового IP-вещания, а также протоколов мультимедиа, напри­мер RTP.

 

 

Рис. 3. Туннелинг группового вещания

RTP

Протокол RTP (Real-lime Transport Protocol) предоставляет транспорт­ные услуги мультимедийным приложениям и позволяет им работать в сетях. RTP не гарантирует доставку и правильный порядок пакетов. Он просто присваивает каждому пакету номер, в результате мультимедий­ные приложения способны обнаружить утерю пакетов или нарушение порядка. Протокол RTP предназначен для работы в режимах передачи «один-одному» или «один-многим».

Обычно RTP передает данные, используя в качестве транспортного механизма протокол UDP, тем не менее он не зависит от транспортных протоколов и может применить другие, например TCP или ATM. Пред­полагается, что каждый RTP-пакет вложен в одни элемент данных ни­жележащего транспортного протокола, например в один UDP-пакет. Когда RTP применяется совместно с транспортным механизмом без сообщений, например TCP, то используется псевдозаголовок, состоя­щий им RTP-заголовка, расположенного за полем длины.

Когда приложение начинает RTP-ceaнc, оно использует два порта: один для протокола RTP, а другой для RTCP (Real-time Control Protocol), опи­санного ниже. При передаче мультимедийных данных задействованы два сеанса — для звука и для видео. Далее описаны некоторые поля RTP-заголовка.

 

 

• Тип полезной нагрузки (Payload Туре) — указывает тип данных, которые несет RTP-накет. Это позволяет приложениям применить правильный кодек для воспроизведения содержимого пакета. При­ложения могут динамически (даже посреди RTP-ceaнса) изменять тип данных исходя иа текущего состояния сети. Один из допустимых типов описан в RFC 1889. В RFC 1890 перечислены значения поля Тип полезной нагрузки и их смысл. Например, число 3 обозначает данные формата GSM, число 26 — формата JPEG (Joinl Photographic Experts Group), число 31 — формата Н.261.

• Порядковый номер (Sequence Number) — 16-разрядное поле, позволяет приложениям выявлять утерю или нарушение последователь­ности пакетов.

• Метка времени (Timestamp) — 32-разрядное поле для синхрониза­ции звуковых и видеопотоков. В этом поле устанавливается произ­вольное начальное значение, которое постепенно увеличивается. Два и более пакета могут иметь одинаковое значение поля Метка време­ни, например два звуковых пакета, соответствующие одному видео­кадру.

Протокол RTP — не надежный транспортный механизм доставки паке­тов в заданной последовательности. Также RTP не обеспечивает управ­ление потоком данных и контроль перегрузки канала — это функции протокола RTCP.

RTCP

Протокол RTCP (Real-Time Control Protocol) работает совместно с RTP, обеспечивая управление потоком данных и контроль перегрузки кана­ла. Участники RTP-сеанса периодически посылают RTCP-пакеты, которые содержат статистические данные: количество отправленных паке­тов, число утерянных и т. д. Отправитель мультимедиа-данных может использовать эту информацию для динамической корректировки ско­рости передачи и даже изменения типа полезной нагрузки. При приме­нении RTCP получатель вправе уведомить отправителя о необходимос­ти изменения скорости передачи, если, например, один из потоков по­ступает слишком быстро по сравнению с другим.

Также RTCP-пакеты несут идентификатор — каноническое имя (canonical name, СNAME). Он используется вкупе с транспортным адресом и но мером порта (например, IP-адрес и UDP-nopr), чтобы уникально иден­тифицировать поток информации.

RTSP

Протокол RTSP (Real-Time Streaming Protocol) — результат совместных усилий компаний RealNetworks и Netscape Communications Corporation. В нем оговаривается, как эффек­тивно осуществлять доставку мультимедиа данных по IP-сетям для при­ложений типа «один-многим». Архитектурно RTSP расположен над RTP и RTCP. Подобно тому, как HTTP осуществляет передачу HTML, RTSP транспортирует мультимедиа-данные. Различие в том, что HTTP-клиент посылает запросы, а сервер обслуживает их, тогда как при применении RTSP запросы формирует как сервер, так и клиент; то есть RTSP — двунаправленный протокол. RTSP реализует передачу данных с помощью TCP или RTP. Сам же RTP способен использовать TCP или UDP.

Протокол RTSP содержит методы установки соединения, управления соединением и запроса объектов. Например, сообщение SET_TRANSPORT позволяет выбрать адреса портов, а также групповой IP-адрес (при груп­повом вещании). Сообщение PLAY_RANGE запрашивает у сервера пе­редачу определенного количества мультимедиа-данных (в миллисекун­дах). Клиент может передать сообщение STOP, аналогичное нажатию кнопки «Пауза». Сообщение SEND_REPORT ил­люстрирует двунаправленность протокола RTSP. Его посылает сервер клиенту, чтобы получить отчет о качестве приема данных.

RTSP предназначен для осуществления взаимодействия клиентов и сер­веров от разных производителей. RTSP содержит механизмы управле­ния, отсутствующие в RTP.

RSVP (Resource Reservation Setup Protocol) — это сигнальный протокол, который используется в Интернете дли резервирования ресурсов сети и маршрутизаторов. RSVP инициализируется получателями, а не отпра­вителями и хорошо масштабируем в сетях со множеством узлов. RSVP определяет путь от отправителя до получателя, основываясь на прото­колах маршрутизации (групповой или одиночной). RSVP-пакеты пересылаются по этому пути от получателя к отправителю. Маршрутизато­ры сначала объединяют запросы от нескольких получателей, а затем передают запрос на выделение ресурсов «против течения» — отправителю. Маршрутизаторы применяют «гибкий режим», то есть получате­ли должны периодически обновлять запрос на выделение ресурсов.

Архитектурно RSVP работает поверх IP, однако идейно он ближе к про­токолам ICMP (Internet Control Message Protocol) и IGMP (Internet Group Membership Protocol), чем к транспортным. RSVP-сообщения иниции­руются хостами от имени приложений. Каждый узел, получивший RSVP-сообщение, выполняет- два действия. Первое направлено на оценку RSVP-сообщения и решение, можно ли выделить запрошенный ресурс. При оценке проверяется наличие ресурсов (так называемая «проверка дос­тупности»), а также наличие у пользователя соответствующих прав (так называемая «проверка стратегии»). Если запрос допустим, то узел вы­полняет второе действие — обновление информации о состоянии. Да­лее запрос передается следующему узлу по обратному пути — от отпра­вителя получателю. Состояние каждого узла считается временным — то есть, запрашивающий узел должен периодически обновлять запрос. В противном случае состояние считается просроченным (и выделенный ресурс освобождается). Сообщения-обновления могут проходить по различным путям Таким образом, если маршрут изменится, то состоя­ния узлов старого маршрута считаются просроченными, и новые ресур­сы будут выделяться по новому маршруту.

 

⇐ Предыдущая123

Поделиться:

Читайте также:

Градостроительное преобразование города как объективная необходимость.
Дискретное преобразование Фурье
Естественные элементы ландшафтов и их преобразование (рельеф, растительность, вода, камни.)
Преобразование исходного кода программ
Совместимость и преобразование типов данных

Воспользуйтесь поиском по сайту: