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

Лекция

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

Считается, что 70% информации - это видео теперь. В чем проблема передачи видео?

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

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

1. вопросы performance

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

3. Поток передачи мультимедийных данных, имеется в виду видео, все остальное не инересует. Мы видим не глазами, а видим головой. Наша голова воспринимает данные только с определенной скоростью – 25-30 фреймов в секунду в процессе передачи.

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

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

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

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

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

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

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

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

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

Когда мы работаем в system mode, бывает, что ос переходит в критическую секцию – это она работает в system mode и меняет свои же параметры в своих же буферах. В этом случае мы тоже должны ос сделать preemptive. Она должна остановиться и передать управление user’скому процессу. Так писать трудно, но это preemptive canal, ядро с перехватом. Это специальные методы написания таких ос – rt linux, остальные не умеют.

Есть еще специальные алгоритмы - rendezvous. Хорошо развито в системах управления баз данных.

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

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