Схемы организации и протоколы Web - вещания.

Содержание
Введение
1. Интернет-вещание и способы его реализации
2. Технологические принципы функционирования интернет-вещания
3. Технологии передачи цифровых видеоизображений
4. Режимы воспроизведения видеоизображений формата MPEG
5. Распространение аудио- и видеоинформации через сеть интернет
6. Технологии IPTV и цифровое телевидение
Заключение
Список использованной литературы

Он постоянно следит за сетью и находит кратчайшие маршруты между сервером и членами каждой группы. MOSPF не совместим с RIP и должен применяться только в тех сетях, где в качестве основного протокола маршрутизации используется OSPF.
Протокол Protocol Independent Multicast (PIM) (Многоадресное вещание, не зависящее от протокола) существует в двух разновидностях: Dense-mode PIM и Sparse-mode PIM. Обе разновидности работают вместе с протоколом IGMP.
Протокол Dense-mode PIM (PIM в "плотном" режиме) совместим как с RIP, так и с OSPF. Подобно протоколу DVMRP, он собирает информацию о подписанных рабочих станциях, опрашивая все сетевые станции и постепенно удаляя те из них, которые не отвечают. Dense-mode PIM используется в тех случаях, когда в некоторой части сети располагается много членов группы и когда имеется широкая полоса пропускания.
Протокол Sparse-mode PIM (PIM в "разряженном" режиме) рассматривает маршрутизаторы как промежуточные точки для определения кратчайших маршрутов между сервером мультимедиа и членами группы. Затем он посылает многоадресные пакеты только тем маршрутизаторам, которые выбраны в качестве промежуточных точек, и с их помощью пересылает пакеты подписанным рабочим станциям. Sparse-mode PIM предназначен для использования в тех сетях, где члены группы разбросаны по удаленным подсетям.
Протоколы для многоадресного потокового вещания в реальном масштабе времени
Описанный в RFC 1889 протокол Real Time Protocol (RTP) (Протокол реального времени) был создан для лучшего управления многоадресным потоковым вещанием в реальном масштабе времени, которое применяется при проведении видеоконференций и в аналогичных приложениях. Для передачи потоковых данных заголовки пакета RTP пересылаются с помощью протокола UDP (а не при помощи протокола TCP, входящего в стек TCP/IP). Работа поверх UDP означает, что UDP-пакет содержит заголовок RTP и полезную нагрузку. В заголовке находится информация о последовательных пакетах, данные для синхронизации видео- и аудиофреймов, а также указание на то, как данные закодированы или сжаты для передачи по сети полезной нагрузки).
Другой протокол, Real Time Transport Control Protocol (RTCP) (Протокол управления доставкой в реальном времени), был создан для того, чтобы позволить сетевым администраторам и разработчикам применять методы компенсации искажений в тех случаях, когда сетевые проблемы влияют на качество работы мультимедийных приложений реального времени. С помощью многоадресных пакетов протокол RTCP позволяет устанавливать качество обслуживания (QoS) для сеансов связи по протоколу RTP RTCP собирает сообщения о членстве от получателей и обеспечивает отправителя обратной связью, сообщающей о заданном качестве обслуживания и о состоянии сети (например, о перегрузке или джиггере). Рассмотрим, к примеру, приложение, которому для передачи цветного видеосигнала и стереофонического аудиосигнала требуется полоса пропускания глобальной сети, построенной на базе линий Т-1. Когда канал Т-1 недоступен и используется резервный канал со скоростью 56 Кбит/с, протокол RTCP может предоставить средства для передачи черно-белого видеосигнала и монофонического аудиосигнала. Также этот протокол позволяет сетевым администраторам использовать средства для анализа производительности сети с мультивещанием и для определения количества подписанных рабочих станций.
Приложения и межсетевые устройства. В Интернете или в корпоративных сетях мультимедийные приложения должны передавать данные через разнообразные межсетевые устройства; настроенные по-разному для пересылки различного типа трафика. Неоднородность сетевых настроек создает проблемы для мультимедийных коммуникаций, которым требуется минимальный набор определенных ресурсов. С этой задачей помогает справиться протокол Resource Reservation Protocol (RSVP) (Протокол резервирования ресурсов). Протокол RSVP позволяет некоторому приложению зарезервировать нужные ему ресурсы (например, полосу пропускания, буферы и класс обслуживания) (рис. 5). С помощью RSVP мультимедийные приложения с потоковым воспроизведением могут сосуществовать с приложениями, передающими данные в виде блоков, однако мультимедийным приложениям дается более высокий приоритет доставки, поскольку они в меньшей степени допускают задержку передачи. Также протокол RSVP удобен для динамического выделения ресурсов при добавлении рабочих станций в группу многоадресного вещания. В некоторых случаях он позволяет просто включить новых подписчиков в группу и использовать ресурсы, уже назначенные этой группе. Более того, отдельные клиентские рабочие станции, входящие в группу, могут запросить другие ресурсы. Например, клиент может пожелать отключить звук или изображение в передаваемом потоке.
Рис.5. Использование протокола RSVP
Протокол RSVP динамически выделяет ресурсы по мере увеличения или уменьшения потребностей. Однако при этом он использует параметры, тщательно подобранные сетевым администратором и гарантирующие минимум полосы пропускания и других ресурсов.
6. Технологии IPTV и цифровое телевидение
Технология IPTV (nternet Protocol Television) (IP-TV, IP-телевидение) представляет собой цифровое интерактивное телевидение в сетях передачи данных по протоколу IP, новое поколение телевидения. Главным достоинством IPTV является интерактивность видеоуслуг и наличие широкого набора дополнительных сервисов (Video on Demand (VoD), TVoIP, Time Shifted TV, Network Personal Video Recorder, Electronic Program Guide, Near Video on Demand). Возможности протокола IP позволяют предоставлять не только видеоуслуги, но и гораздо более широкий пакет услуг, в том числе интерактивных и интегрированных.
Помимо основных, IPTV может включать в базовый пакет услуг ряд дополнительных сервисов (Video Telephony, Voting, Information Portals, Web, Games, MOD KOD). Это возможно на основе унификации и стандартизации различных оконечных устройств, интеграции звука, видео и данных на основе IP-протокола и предоставления услуг на единой технологической платформе.
В IPTV есть возможность использовать для одного видеоряда двух и более каналов звукового сопровождения, например на русском и английском языках, сами каналы, при этом, полифонические. IPTV функционирует в IP-сетях на основе следующих протоколов:
- HTTP — для организации интерактивных сервисов (пользовательских меню и пр.)
- RTSP — для управления потоками вещания.
- RTP — для передачи потокового видео.
- IGMP — для управления мультикаст-потоками.
Видео передается в формате MPEG с использованием сжатия MPEG-2 или MPEG-4, как правило, со скоростью 4мбит/с.
Протокол Video on Demand (VoD) (видео по требованию) (IP-UNICAST) — видео по запросу, система индивидуальной доставки абоненту телевизионных программ или видеофильмов по кабельной сети с мультимедиасервера в формате MPEG. Video on Demand является своего рода маленьким электронным видеопрокатом, когда фильм можно в любое время заказать из каталога, при этом часто поддерживаются дополнительные функции, такие как перемотка, остановка и выключения.
В России услуга видео по запросу только начинает распространятся, во многом в связи с дороговизной интернета за пределами больших городов. Разработкой оборудования для VOD систем у нас занимаются фирмы Motorolla и Alcatel.
Протокол TVoIP (Телевидение по протоколу IP или IP-телевидение) (IP-MULTICAST) — это цифровая трансляция видеоконтента (телеканалов) одновременно для всех телезрителей с возможностями навигации по каналам в едином пакете каналов.
Time Shifted TV (сдвинутое во времени вещание) — система телевидения, при которой можно заранее заказать просмотр транслируемой передачи «со сдвигом» на удобное время.
Network Personal Video Recorder (NPVR) (сетевой персональный видеомагнитофон) (IP-UNICAST) — cервис цифрового телевидения сетевой персональный видеомагнитофон, который позволяет записать любую из транслируемых телепередач и посмотреть сколько угодно раз в удобное время, а также стереть. Сервис сохранения контента в сети с целью последующего индивидуального просмотра.
Electronic Program Guide, (EPG) (электронный ТВ гид) - интерактивная программа передач в рамках IPTV или Цифрового Кабельного Телевидения; услуга в области цифрового телевидения. EPG обеспечевает гибкость в управлении видеоконтента.
Near Video On Demand, (NVoD, nVOD,n-VOD) (почти видео по требованию) (IP-MULTICAST) — cервис цифрового телевидения «виртуальный кинозал» или «карусельное видео», многоадресное вещание предварительно сформированного видеоконтента по расписанию в несколько потоков со смещением во времени как правило для платного просмотра.
RTSP (Real Time Streaming Protocol) — потоковый протокол реального времени. Реализует для мультимедийного контента функции прокрутки вперёд и назад, останова и т. д. RTSP не выполняет сжатие, а также не определяет метод инкапсуляции мультимедийных данных и транспортные протоколы. RTSP-сообщения посылаются отдельно от мультимедийного потока. Для них используется специальный порт с номером 554. RTSP-канал во многом напоминает управляющий канал протокола FTP.
Протокол RTP (Real-Time Protocol) работает на транспортном уровне поверх протокола UDP и используется при передаче трафика реального времени. Протокол RTP переносит в своём заголовке данные, необходимые для восстановления голоса или видеоизображения в приёмном узле, а также данные о типе кодирования информации (JPEG, MPEG и т. п.). В заголовке данного протокола, в частности, передаются временная метка и номер пакета. Эти параметры позволяют при минимальных задержках определить порядок и момент декодирования каждого пакета, а также интерполировать потерянные пакеты.
RTP не имеет стандартного зарезервированного номера порта. Единственное ограничение состоит в том, что соединение проходит с использование четного номера, а следующий нечетный номер используется для связи по протоколу RTCP. Тот факт, что RTP использует динамически назначаемые адреса портов, создает ему трудности для прохождения межсетевых экранов, для обхода этой проблемы, как правило, используется STUN-сервер. Установление и разрыв соединения не входит в список возможностей RTP, такие действия выполняются сигнальным протоколом (например, протоколом SIP).
Таблица 4. Структура пакета
+ Биты 0-1 2 3 4-7 8 9-15 16-31 0 Ver. P X CC M PT Порядковый номер 32 Метка времени 64 SSRC-идентефикатор 96 ... CSRC-идентефикаторы ... 96+(CC×32) Дополнительный заголовок (необязательный), содержит длину блока данных - "AHL" 96+(CC×32)+ (X×(AHL+16)) Данные
Ver. (2 бита) указывает версию протокола. Текущая версия - 2. P (один бит) используется в случаях, когда RTP-пакет дополняется пустыми байтами на конце. X (один бит) используется для указания расширений протокола, задействованных в пакете. CC (4 бита) содержит количество CSRC-идентификаторов, следующих за постоянным заголовком. M (один бит) используется на уровне приложения и определяется профилем. Если это поле установлено, то данные пакета имеют какое-то особое значение для приложения. PT (7 бит) указывает формат полезной нагрузки и определяет её интерпретацию приложением. SSRC указывает источник синхронизации.
IGMP (Internet Group Management Protocol — протокол управления группами Интернета) сетевой протокол, используется узлами в сети, основанной на протоколе IPv4, для сообщения принадлежности к IP-группе сетевым маршрутизатором, а также выполнения других функций управления групповой маршрутизацией.
IGMP версии 3 определён в RFC 3376. Предыдущие версии IGMP определены в RFC 2236 (версия 2) и RFC 1112 (версия 1). Версия 2 позволяет маршоутизатору быстрее обнаружить, что членов какой-либо IP-группы больше нет. В версии 3 была добавлена поддержка фильтрации адресов. С помощью этого механизма узел может сообщить, с каких адресов он хочет получать пакеты, а с каких нет. На рис. 6 показаны операции, которые выполняются у получателя мультимедийной информации при потоковом воспроизведении.
Рис.6. Действия клиента мультимедийного потока
При совместной передаче речи, видео и данных по сети вся эта информация должна быть синхронизирована программами у получателя, т. е. нужно, чтобы все последовательные фрагменты были собраны и воспроизведены в правильном порядке. Синхронизация надежнее всего в тех случаях, когда имеется полоса пропускания, достаточная для приложения, благодаря чему отсутствуют потери разрядов или кадров, а также нет слишком больших задержек, вызванных перегрузкой сети. Синхронизация полученной информации становится еще сложнее, если часть информации или все данные сжаты и должны быть распакованы и синхронизированы одновременно.
В потоковых мультимедийных приложениях это нужно делать сразу же при получении информации. Иногда аудиосигналы смешиваются из разных источников, и получаемый сигнал требует дополнительной синхронизации.
Заключение
Мультимедийные коммуникации стали значительно сложнее, они постепенно и незаметно сливаются с традиционными операциями передачи данных. Кроме того, объединяются телефония, телевидение и компьютерные технологии, в результате чего появляются такие средства, как интернет-телефония, цифровое телевидение и операционные системы (Red Hat Linux 7.x и Windows XP) с мультимедийными возможностями. Многие из нас уже встречались с интегрированными технологиями в следующих областях:
- аудио- и видеоконференции;
- компьютерная профессиональная подготовка;
- цифровое и интерактивное телевидение;
- промышленное роботостроение и управление механизмами;
- компьютерные киоски для информационных служб;
- интерактивные игры.
- Интернет-телевидение.
В ближайшие годы у мультимедийных средств и интегрированных сетевых служб появится множество новых привлекательных возможностей.. Мультимедийные приложения лишь только сейчас позволили в полной мере увидеть потенциал персональных компьютеров и сетей в области коммуникаций, стимулируя общение людей, находящихся на больших расстояниях, реализуя возможности удаленного обучения и предоставляя средства коллективной работы при решении задач.
Одним из самых перспективных вариантов использования мультисервисных сетей является передача телевизионного и видеотрафика по протоколу IP. Согласно данным аналитических агентств, на конец 2006 г. российская аудитория пользователей IPTV составляла около 70 тыс. абонентов. По прогнозам, уже к концу 2010 г. количество абонентов IPTV может превысить 1 млн.
Внедрение решений по передаче видеотрафика позволяет операторам более эффективно использовать свою сеть за счет предоставления современных интерактивных сервисов. Благодаря мультисервисной природе данной услуги, существует возможность реализации гибкой функциональности, существенно повышающей интерес абонентов к IPTV: организация потокового телевещания, «видео по запросу» (Video-on-Demand – VoD), запись ТВ-программ по запросу, интерактивное ТВ, видеотелефон для абонентов оператора и др.
Список использованной литературы
Давиташвили Г. Интернет-телевидение – альтернатива или метаморфоза? // http://www.internews.ru/teleforum2006/thesis4.html
2. Спорышев Р. Интерактивное телевидение в мире и в России // Ростовская электронная газета. – 2006. – № 59 / www.relga.ru.
3. Иткис Г.Е., Жильцов В.А. Сеть Русмедиа. Обзор проектов для вещателей // Сборник НАТ. – 2007. – Октябрь. – С. 176–178.
4. Кан Р. Е. Эволюция сети Интернет. Всемирный доклад ЮНЕСКО по коммуникациям и информации. 2004 гг., «Бизнес-Пресс», М.: 2004 г.
5. Коваленко В., Дмитрий Корягин. Вычислительная инфраструктура будущего. «Открытые системы», №11-12, 2007, с. 45-52.
6. Крол Э. Все об Internet: Пер. с англ. – К.: Торгово-издательское бюро BHV, 2005. 592 с.
7. Мендкович А. С., Русаков А. И., Захарова М. Н., Зильберман М. Л. Развитие систем сетевых видеоконференций. // Тезисы докладов Всероссийской научно-методической конференции «Телематика’06», СПб., 8-11 июня 20068 г., СПб., 2006, с. 80-82.
7. Норенков И.П. , Трудоношин В.А.. Телекоммуникационные технологии. М., 2004.
Иткис Г.Е., Жильцов В.А. Сеть Русмедиа. Обзор проектов для вещателей // Сборник НАТ. – 2007. – Октябрь. – С. 176–178.
Давиташвили Г. Интернет-телевидение – альтернатива или метаморфоза? // ttp://www.internews.ru/teleforum2006/thesis4.html
Давиташвили Г. Интернет-телевидение – альтернатива или метаморфоза? //http://www.internews.ru/teleforum2006/thesis4.html
Кан Р. Е. Эволюция сети Интернет. Всемирный доклад ЮНЕСКО по коммуникациям и информации. 2004 гг., «Бизнес-Пресс», М.: 2004 г.
Коваленко В., Дмитрий Корягин. Вычислительная инфраструктура будущего. «Открытые системы», №11-12, 2007, с. 45-52.
Крол Э. Все об Internet: Пер. с англ. – К.: Торгово-издательское бюро BHV, 2005. 592 с.
Крол Э. Все об Internet: Пер. с англ. – К.: Торгово-издательское бюро BHV, 2005. 592 с.
Крол Э. Все об Internet: Пер. с англ. – К.: Торгово-издательское бюро BHV, 2005.стр. 344-352
Крол Э. Все об Internet: Пер. с англ. – К.: Торгово-издательское бюро BHV, 2005. стр. 410-412
Крол Э. Все об Internet: Пер. с англ. – К.: Торгово-издательское бюро BHV, 2005. стр. 447
Иткис Г.Е., Жильцов В.А. Сеть Русмедиа. Обзор проектов для вещателей // Сборник НАТ. – 2007. – Октябрь. – С. 176–178.
Норенков И.П. , Трудоношин В.А.. Телекоммуникационные технологии. М., 2004., стр. 218-222
Норенков И.П. , Трудоношин В.А.. Телекоммуникационные технологии. М., 2004, стр. 276.
24