ПОТОКОВАЯ ПЕРЕДАЧА МУЛЬТИМЕДИЙНОЙ ИНФОРМАЦИИ В ИНФОРМАЦИОННЫХ СЕТЯХ

Возможности интернет провайдеров обеспечить широкополосный доступ в интернет даже в самых отдаленных регионах, подталкивают владельцев интернет ресурсов создавать более функциональные, но в то же время сложные и массивные веб-приложения, требующие высоких скоростей передачи данных и низкого время отклика. Использование мультимедийных сервисов в современных информационных сетях получило широкое распространение — все больше людей предпочитают использовать IPTV [3] вместо приема аналогового сигнала через антенну и сервисы просмотра мультимедийных материалов онлайн вместо привычной покупки мультимедийных дисков в магазине.

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

Сжатие мультимедийных материалов используется не только при передаче, но и при хранении данных. Существует множество стандартов сжатия видео, однако, в последнее время, большинство мультимедийных файлов конвертируется с использованием стандарта H. 264 [13].

Стандарт H. 264 отличается высокой эффективностью сжатия видео, относительно предыдущих стандартов, благодаря расширенному списку возможностей обработки исходного видео, таких как:

·     Многокадровое предсказание, включающее в себя: использование предыдущего кадра в качестве основы для последующего, обработку только изменяющегося фрагмента кадра с возможностью ссылки на предыдущий кадр до 32 раз и многие другие улучшения;

·     Сжатие макроблоков без потерь, за счет более точного описания области макроблока;

·     Переменные размеры блока сжатия, что позволяет точно выделить края движущихся объектов;

·     Функции устойчивости к ошибкам.

Использование возможностей стандарта: выбор степени сжатия и качества исходного изображения, зависит от потребностей текущей задачи передачи данных. Стандарт подразумевает несколько предустановленных вариантов сжатия — профили, предустановок которых, в большинстве случаев, хватает для всех типов задач. В рамках наших задач, можно выделить несколько профилей сжатия видео:

·     Базовый профиль (baseline) — используется для видеоконференций и мобильных продуктов. Отличается высокой устойчивостью к потере в процессе передачи данных;

·     Основной профиль (main) — используется при передаче цифрового телевидения стандартной четкости;

·     Расширенный профиль (extended) — используется при передаче потокового видео, высокая степень сжатия с дополнительной устойчивостью к потере данных;

·     Высокий профиль (high) — используется при передаче цифрового телевидения высокой четкости.

Вместе с передачей видео потока, требуется передавать и аудио, которое тоже требует сжатия. Основным протоколом для сжатия стерео звука, получившего наиболее широкое распространение в интернете, является MP3 (MPEG-1 layer 3 [4]). Кодек использует спектральное отсечение с использованием оптимальных критериев, в зависимости от требований к выходному потоку. Оптимальным, для передачи потокового аудио, является битрейт в 128 кбит\сек. Он обеспечивает не только приемлемое качество звука для потокового видео стандартной четкости, но и низкую потребность в пропускной способности канала передачи данных.

Для передачи более качественного аудио сигнала и использования большего количества каналов (до 8 звуковых каналов) используется кодек AC3 (Audio Coding 3 [12]), более знакомый всем как Dolby Digital. Существует несколько технологий, расширяющих возможности Dolby Digital. Такой кодек используется начиная передачей потокового видео высокой четкости, заканчивая IMAX.

Кроме сжатия мультимедийных данных, требуется обеспечение возможности беспрерывной передачи их удаленному пользователю. Есть несколько типов передачи потокового мультимедиа контента:

·     В режиме реального времени (multicast [5]), когда один поток данных передается многим пользователям одновременно. По такому принципу работает IPTV;

Рисунок 1. Принцип передачи пакетов multicast

·     В режиме «по запросу» (unicast [10]), сервер формирует индивидуальный поток данных для каждого клиента. В данном режиме работают большинство интернет сервисов передачи мультимедиа.

Рисунок 2. Принцип передачи пакетов unicast

Оба режима требуют высокой пропускной способности и низких временных задержек интернет канала пользователя. В зависимости от оборудования, настроек и топологии сети, потоки передаются с использованием протоколов HTTP [6] или RTP.

Протокол передачи потокового видео RTP (Real-time Transport Protocol [7]) базируется, в основном, на UDP (User Datagram Protocol [11], ключевой элемент стека протоколов TCP\IP), хотя в спецификации обозначена возможность работы через TCP (Transmission Control Protocol [9], ключевой элемент стека протоколов TCP \ IP). Использование UDP в качестве базового протокола для передачи мультимедийных данных, обусловлено необходимостью возможных потерь пакетов в пользу минимизации задержек передаваемой информации.

Так как протокол RTP не имеет возможности установления соединения, его использование не возможно без применения дополнительных протоколов, таких как RTSP или SIP:

·     Протокол RTSP (Real Time Streaming Protocol), являясь прикладным протоколом, используется для удаленного управления потоком данных с сервера. Как клиент, так и сервер могут создать запрос, используя определенный формат. Запрос передается в текстовом виде и может содержать дополнительные поля с указанием параметров передачи. Итогом взаимодействия сервера и клиента является установление соединения.

Рисунок 3. RTP с использованием RTSP на примере IPTV

·     Протокол SIP (Session Initiation Protocol [8]), так же является протоколом прикладного уровня и используется для описания способа установки соединения между двумя и более узлами с целью передачи мультимедийного содержимого. Протокол имеет клиент-серверную архитектуру: клиент запрашивает определенную информацию с сервера; сервер обрабатывает запрос клиента и формирует ответ о возможности установки соединения.

Рисунок 4. RTP с использованием SIP на примере VOIP

Установка соединения для работы по протоколу RTP, подразумевает создание отдельных сессий для аудио и видео, занимающие четные порты. Следующий (нечетный) порт занимает вспомогательный протокол RTCP (Real-Time Transport Control Protocol [1]), отвечающий за синхронизацию медиа потоков данных и обратную связь с сервером. Поток данных, создаваемый RTCP, в общем случае не превышает 5 % от общего трафика RTP.

Пакет RTP содержит в заголовке временную метку и порядок пакета, что позволяет с минимальными потерями времени собрать видеоряд в правильную последовательность и пропустить отсутствующие пакеты.

Кроме RTP существует возможность передачи мультимедиа через HTTP, а именно HLS (HTTP Live Streaming [2]). В таком случае установка соединения и передача мультимедийной информации происходят внутри одного протокола. Синтаксис команд схож с RTSP и содержится в заголовке HTTP пакета. Поддержка HLS интегрирована в большинство современных мобильных устройств и медиа проигрывателей, что позволяет широко использовать этот способ передачи потокового мультимедиа, а отсутвие сложностей при использовании портов нестандартных портов снимает ограничение на использование потокового мультимедиа в неподготовленных сетях.

Рисунок 5. Общая схема передачи данных HLS

Минусом данной технологии, является значительная задержка, обусловленная особенностями работы протокола, недопустимая при использовании мультимедиа потоков для организации диалога между удаленными пользователями. Однако это ограничение не существенно, при передаче HD видео и аудио сигнала.

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

Список литературы:
1.    Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets — [Электронный ресурс] — Режим доступа. — URL: http://tools.ietf.org/html/rfc4571 (дата обращения 03.04.2014).
2.    HTTP Live Streaming Overview — [Электронный ресурс] — Режим доступа. — URL: https://developer.apple.com (дата обращения 05.04.2014).
3.    IPTV — [Электронный ресурс] — Режим доступа. — URL: http://megabook.ru/article/IPTV (дата обращения 02.04.2014).
4.    Moving Picture Expert Group— [Электронный ресурс] — Режим доступа. — URL: http://adobefaq.narod.ru/mpeg1234.html (дата обращения 01.04.2014).
5.    Multicast over TCP/IP HOWTO — [Электронный ресурс] — Режим доступа. — URL: http://www.tldp.org/HOWTO/Multicast-HOWTO.html (дата обращения 01.04.2014).
6.    RFC 2068. Протокол передачи гипертекста — HTTP/1.1— [Электронный ресурс] — Режим доступа. — URL: http://www.lib.ru/WEBMASTER/rfc2068/rfc2068rus.txt (дата обращения 02.04.2014).
7.    RTP Payload Format for H.264 Video— [Электронный ресурс] — Режим доступа. — URL: http://tools.ietf.org/html/rfc6184 (дата обращения 03.04.2014).
8.    SIP: Session Initiation Protocol — [Электронный ресурс] — Режим доступа. — URL: http://tools.ietf.org/html/rfc3261 (дата обращения 04.04.2014).
9.    TRANSMISSION CONTROL PROTOCOL — [Электронный ресурс] — Режим доступа. — URL: http://tools.ietf.org/html/rfc793 (дата обращения 04.04.2014).
10.    Unicast, Multicast, Broadcast — [Электронный ресурс] — Режим доступа. — URL: http://infocisco.ru/types_communication.html (дата обращения 02.04.2014).
11.    User Datagram Protocol — [Электронный ресурс] — Режим доступа. — URL: http://tools.ietf.org/html/rfc768 (дата обращения 04.04.2014).
12.    Руководство по HD-звуку — [Электронный ресурс] — Режим доступа. — URL: http://www.thg.ru/video/hd_audio_i/hd_audio_i-01.html (дата обращения 01.04.2014).
13.    Стандарт сжатия видеоизображения H.264— [Электронный ресурс] — Режим доступа. — URL: http://wisol.ru/articles/standart-H264 (дата обращения 01.04.2014).