2. Понятие мультимедиа. Понятие потока. Особенности и требования к ос сетевых устройств

к

Лекция

Multi media системы – голос, видео – составные части системы. Однако видео – очень необычный вид передачи данных. Видео требует, чтобы мы получили определенные действия – delivery или передача за определенный период времени. Для того, чтобы добиться и того и другого нужно предпринять массу действий.

В чем проблема передачи видео?

Здесь возникает понятие потока – стрима.

Stream в ос используется в трех вариантах:

1. вопросы performance

2. технология написания драйверов. Передается запрос потоком, он от upper level передается ниже при помощи определенного потока параметров: передаю сначала udp к ip, от ip к драйверам и т.д. до тех пор, пока не дойдем до драйверов адаптера, до канальных протоколов, которые сейчас хардвеерные.

3. Поток передачи мультимедийных данных, имеется в виду видео, все остальное не интересует.

Требования к мультимедийным серверам:

• Поскольку везде 345 мегабит в секунду не везде можно обеспечить, займемся компрессией – сжимать данные, чтобы передать больше. Любе устройство, передающее мультимедиа, должно уметь compression и decompression. Компрессия бывает с полным и неполным восстановлением. Полное нам не надо, потому что мы передаем не данные, а видео. Алгоритм mpeg – умеет передавать до 15 мбит в сек.

• Должны иметь мультимедийные расписания, то есть расписания с перехватом, иначе не уложимся в эти 25-30 фреймов в секунду. Любая ос должна обрабатывать такие запросы переодически. Это значит, что раз в доле милисекунды идет кусочек информации - периодический процесс.

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

• Для того, чтобы передавать с перемотками надо иметь спец. сетевые протоколы. Такие протоколы прикладные.

• Admission control protocol – Эта спецификация для каждого вида устройства своя. «Я обращаюсь к коммутатору. Говорю: дай мне буфер, если у тебя он есть. Дай мне кредит. И буду передавать, только если кредит дается, тогда я выдержу временные характеристики» - так работают коммутаторы в data центрах. С помощью спец. средств там есть возможность переключаться вас на любой порт, буфер любого порта вас обслужит.

• Все процессоры должны иметь CPU scheduling, и он должен быть real time, удовлетворял требованиям передачи мультимедиа. В первую очередь мы не можем вводить динамические приоритеты, они все фиксированы, иначе мы не успеем в периодические процессы.

• У нас есть диски и подсистемы ввода-вывода. Если мы передаем 15 гб фильм. Хорошо бы куда-нибудь записать, в частности диска мультимедийного сервера и оттуда делать стриминг. Но тогда вся подсистема ввода-вывода должна иметь спец. алгоритмы.

• Jitter, он дрожит между фреймами, его надо как-то убрать. Для этого есть специальный протокол RTP – real-time protocol, который работает вместе с протоколом RTCP. Описано все в протоколе rfc. Протоколы 7ого уровня, кладутся поверх udp. В RTP есть метка времени, зная это время я могу убирать ненужное и получать стрим без jitter’а. А RTCP нужен, чтобы управлять RTP.

• Нам еще надо делать перемотку. Для этого используется спец. протокол RTSP – real-time streaming protocol. По такому протоколу 7 уровня должен работать мультимедийный сервер, или у оператора связи, чтобы делать нам undemand, чтобы делать нам перевод. Потому что у этого протокола есть спец команды: setup, play, redund, pause.

• Еще мы передаем огромные данные, причем всем. Все это делается в режиме multicast. Есть три режима ос рутера для передачи: multicast, broadcast, unicast. Unicast – передаю кому-то одному (по одному ip). Multicast – по множествам ip. Broadcast – всем.