Мультимедиа

Трафик в реальном масштабе времени через Интернет

В этой лекции рассмотрим нагрузку (трафик) в реальном масштабе времени и ее обработку в Интернете. Большинство людей используют термины "нагрузка в реальном масштабе времени" и "мультимедиа-нагрузка" как взаимно заменяемые. Однако не всякий мультимедиа-трафик нуждается в обработке в реальном масштабе времени.

Чтобы отличить связь в реальном масштабе времени от других типов связи, необходимо определить трафик в реальном масштабе времени. Неформально, игнорируя короткие задержки при передаче, — это почти одновременное производство и использование данных. Другими словами, передатчик вырабатывает данные, посылает их в Интернет, а приемник использует их. Обычно, когда приемник использует полученные данные, следующая часть еще в производстве.

Пример 1

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

Пример 2

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

Характеристики

Данные в реальном масштабе времени имеют характеристики, обычные для всех типов данных (аудио, видео и текста).

Временные соотношения

Данные в реальном масштабе времени на сети пакетной коммутации требуют сохранения временных соотношений между пакетами сеансов. Например, предположим, что видео-сервер, работающий в реальном масштабе времени, создает живые изображения и посылает их по линии. Видео переводится в цифровую форму и пакетизируется. Имеется только три типа пакетов, и каждый пакет содержит 10 секунд видеоинформации. Первый пакет стартует в 00:00:00, второй — в 00:00:10, а третий пакет в 00:00:20. Также изображение требует одной секунды (преувеличено для простоты) для каждого пакета, чтобы достичь пункта назначения (задержка одинаковая). Приемник может воспроизводить первый пакет в 00:00:01, второй пакет в 00:00:11 и третий пакет в 00:00:21. Хотя имеется односекундная разница между тем, что видит оператор камеры и приемная сторона и что удаленный зритель видит на экране компьютера, действие происходит в реальном масштабе времени. Соотношение между пакетами сохраняется. Односекундная задержка не имеет значения. Рисунок 17.1. иллюстрирует эту идею.

Рис. 17.1. Временные соотношения

Но что произойдет, если пакеты прибывают с различной задержкой? Например ( рис. 17.2.а) первый пакет прибывает в 00:00:01 (односекундная задержка), второй в 00:00:15 (пятисекундная задержка) и третий в 00:00:27 (семисекундная задержка). Если приемник начинает воспроизведение первого пакета в 00:00:01, он закончит в 00:00:11, однако следующий пакет еще не прибудет; он прибудет на 4 секунды позднее. Имеется промежуток между первым и вторым пакетом и между вторым и третьим, — это приведет к помехам на дальней стороне.

Метка времени

Один из методов решения проблемы джиттера– использование меток времени. Если каждый пакет имеет метку времени, которая указывает время его создания относительно первого (или предыдущего) пакета, то приемник может дополнить это время ко времени начала воспроизведения. Другими словами, приемник знает, когда каждый пакет должен быть воспроизведен. Допустим, первый пакет в предыдущем примере имеет временную метку 0, второй имеет временную метку 10 и третий временную метку 20. Если приемник начинает воспроизводить первый пакет в 00:00:08, второй в 00:00:18, а третий в 00:00:28, то зазора между пакетами не возникнет. Рис. 17.2б. показывает такую ситуацию.

Рис. 17.2. Принцип передачи информации с учетом задержки

Буфер воспроизведения

Чтобы отделить время прибытия от времени воспроизведения, нам нужен буфер для накопления данных, пока они воспроизводятся. Этот буфер называется буфером воспроизведения. Когда начинается сеанс (прибывает первый бит первого пакета), приемник задерживает воспроизведение данных, пока не будет достигнут порог. В предыдущих примерах первый бит первого пакета прибывал в 00:00:01; порог 7 с., время воспроизведения 00:00:08. Порог измеряется в единицах времени блока данных. Ответ не должен начинаться, пока время единицы данных не равно значению порога.

Данные накапливаются в буфере, возможно, с переменной скоростью. Заметим, что количество данных в буфере будет сокращаться и расширяться, но пока задержка меньше, чем время воспроизведения, количество данных не имеет джиттера. Рис. 17.3. показывает буфер с различными временами для нашего примера.

Рис. 17.3. Буфер воспроизведения

Упорядочение

В дополнение к временным соотношениям информации и меткам времени для трафика, работающего в реальном масштабе времени, необходимо еще одно свойство. Нам нужен порядковый номер для каждого пакета. Метка времени не может информировать приемник, если пакет потерян. Например, предположим, что метки времени — 0, 10, 20. Если второй пакет потерян, приемник получает только два пакета с метками времени 0 и 20. Приемник предполагает, что пакет с меткой 20 — это второй по порядку пакет,который послан через 20 секунд после первого. Приемник не имеет средств для того, чтобы узнать, что второй в этой последовательности пакет на самом деле потерян. Чтобы разобраться в этой ситуации, пакетам необходимо присвоить последовательный номер.

Циркулярная рассылка

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

Трансляция

Иногда трафик, работающий в реальном масштабе времени, нуждается в трансляции. Транслятор – это компьютер, который может изменить формат широкополосного видео в низкокачественный сигнал с узкой полосой. Это нужно, например, для источника, который порождает сигнал 5 Мбит/с и посылает его к получателю, имеющему полосу, меньшую чем 1 Мбит. Для получения сигнала транслятору нужно декодировать сигнал и закодировать опять в сигнал более низкого качества, который нуждается в меньшей полосе.

Смешивание

Если имеется более чем один источник, который может посылать данные в одно и то же время (как в видео- и аудиоконференциях), тогда трафик состоит из многих потоков. Чтобы уменьшить трафик к одному источнику, данные от различных источников могут быть смешаны в один источник. Смешивание – это математическое сложение сигналов, поступающих от различных источников, для того чтобы создать единственный сигнал.

Поддержка от протокола транспортного уровня

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

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

UDP более пригоден для мультимедиа — трафика реального времени. UDP поддерживает циркулярную передачу, но не имеет стратегии повторной передачи. Однако UDP не обеспечивает метки времени, последовательной нумерации или смешивания.

RTP

Транспортный протокол реального масштаба времени (Real-time Transport Protocol — RTP) — протокол, который разработан, чтобы приспособить трафик, работающий в реальном масштабе времени, к Интернету. RTP не имеет механизма доставки (циркулярного вызова, номеров портов и тому подобного); он должен использоваться с UDP. RTP находится в стеке протоколов TCP/IP между UDP и прикладной программой. Главный вклад RTP — введение механизма для меток времени, последовательностей и смешивания.