МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ
(ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)
Кафедра Информационно-коммуникационные технологии
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к дипломному проекту
На тему: «Разработка клиентской части платформы видеовзаимодействия Viditory»
Студент:
Руководитель проекта: к. т.н., доцент
Допущен к защите __________________2011 г.
Консультанты проекта:
Специальная часть
Охрана труда
Зав. кафедрой проф. д. т.н.
Москва 2011
Аннотация
В данной работе проведен анализ платформ для разработки сервисов видеовзаимодействия. Разработаны следующие элементы клиентской части платформы Viditory:
· Зрительское представление;
· Редактор шаблонов;
· Воспроизведение записи.
Выявлены дополнительные задачи для доработки платформы.
Содержание
Аннотация. 2
Содержание. 3
1. Введение. 7
1.1. Актуальность. 7
1.2. Цель и задачи. 7
1.3. Практическая значимость. 7
1.4. Апробация. 8
1.5. Завершенность. 8
1.6. Структура и объем работы.. 8
2. Постановка задачи. 9
2.1. Задачи на исследование. 9
2.2. Задачи на разработку. 9
3. Обзорно-аналитическая часть. 10
3.1. Анализ существующих решений в области видеовзаимодействия. 10
3.2. Обзор технологических решений для разработки RIA.. 10
3.2.1 Adobe Flash Platform.. 11
3.2.2 Java applet 12
3.2.3 Microsoft Silverlight 12
3.2.4 HTML5 и JavaScript 12
3.3. Выбор платформы для разработки. 12
3.4. Выбор сервера для построения системы.. 13
4. Технологическая часть. 14
4.1. Обзор IDE FlashDevelop. 14
4.2. Обзор Flex SDK.. 14
4.3. Обзор взаимодействия с сервером.. 15
4.3.1. Real-Time Messaging Protocol (RTMP) 15
4.3.2. Action Message Format (AMF 3) 15
4.3.3. SharedObject 17
5. Разработка. 18
5.1. Разработка архитектуры системы.. 18
5.1.1. Основные понятия. 18
5.1.2. Система прямого эфира. 18
5.1.3. Система записи. 19
5.1.4. Загрузка конфигурационного файла. 20
5.2. Разработка среды управления событием в режиме реального времени. 20
5.2.1. Авторизация. 20
5.2.2. Права пользователей. 21
5.2.6. Формат основного удаленного общего объекта. 22
5Контроль состояния соединения с сервером.. 24
5.2.4. Управление удаленными общими объектами. 26
5.2.5. Управление аудио и видео потоками. 27
5.3. Разработка зрительского представления. 29
5.3.1. Управление событием.. 30
5.3.2. Управление чатом.. 31
5.3.3. Управление титрами. 31
5.3.4. Вещание. 31
5.3.5. Формат удаленных общих объектов для презентации, чата и видео. 33
5.4. Разработка редактора шаблонов. 35
5.4.1. Добавление источников. 35
5.4.2. Изменение источников объектов. 36
5.4.3. Управления источниками звука в шаблоне. 36
5.4.4. Создание новых шаблонов на основе макетов. 36
5.4.5. Взаимодействие редактора шаблонов с сервером.. 37
5.5. Разработка воспроизведения записей. 38
5.5.1.Разработка формата xml файла для воспроизведения записи. 38
5.5.2. Обработка входных данных. 40
5.5.3. Взаимодействие между объектами при воспроизведении записи. 41
5.6. Перспективы разработки. 44
5.6.1. Разработка рабочего места режиссера. 44
5.6.2. Доработка редактора шаблонов. 44
5.6.3. Использование Acoustic Echo Cancellation. 44
5.6.4. Монтаж записей. 44
5.6.5. Добавление новых интерактивных элементов. 44
5.6.6. Разработка версии для портативных мультитач устройств. 45
6. Экспериментальная часть. 46
6.1. Оценка соответствия разработанной системы техническому заданию.. 46
6.2. Внедрение платформы Viditory в сервис 46
6.3. Испытание системы в рабочих условиях. 46
7. Охрана труда. 48
7.1. Исследование возможных опасных и вредных факторов при эксплуатации ЭВМ и их влияния на пользователей. 48
7.1.1 Введение. 48
7.2 Анализ влияния опасных и вредных факторов на пользователя. 50
7.2.1. Влияние электрического тока. 50
7.2.2. Влияние статического электричества. 51
7.2.3. Влияние электромагнитных излучений НЧ.. 51
7.2.4. Влияние ультрафиолетового излучения. 52
7.2.5. Выводы.. 52
7.3. Методы и средства защиты пользователей от воздействия на них опасных и вредных факторов 52
7.3.1. Методы и средства защиты от поражения электрическим током.. 52
7.3.2. Методы и средства защиты от ультрафиолетового излучения. 54
7.3.3. Методы и средства защиты от электромагнитных полей низкой частоты.. 55
7.3.4. Методы и средства защиты от статического электричества. 55
7.3.5.Эргономические требования к рабочим местам к ПЭВМ... 56
7.4. Выводы.. 59
8. Заключение. 60
8.1. Итоги. 60
8.2. Выводы.. 60
9. Список публикаций. 61
Литература. 62
1. Введение
1.1. Актуальность
На фоне растущего спроса на сервисы видеовзаимодействия в Интернет явно вырисовывается нехватка комплексных решений. Существует множество сервисов для трансляций, для телемостов, для презентаций, но все эти задачи одновременно не решает ни один из существующих сервисов. При организации масштабных событий требуются возможность управления событием со стороны режиссера, служебная связь, автоматическая публикация события и возможность монтажа. Таким образом, решение, позволяющее реализовать весь этот функционал, найдет своих пользователей, как среди пользователей Интернет, так и среди инженеров телевидения и в event-индустрии.
1.2. Цель и задачи
Создать инструмент для проведения видеовзаимодействия в Интернет, заменяющий по функциональным возможностям профессиональные телевизионные системы, при этом сохранив простоту работы и минимум требований к оборудованию.
В разработке клиентской части ставились основные задачи:
· Разработать зрительское представление;
· Разработать редактор шаблонов;
· Разработать воспроизведение записи;
В качестве дополнительных задач, которые не были выполнены, но относятся к списку перспективных доработок платформы Viditory, относятся:
· Разработать рабочее место режиссера;
· Разработать служебную связь;
· Разработать возможность объектного монтажа записи события.
1.3. Практическая значимость
Ещё на этапе разработки система вызвала высокий интерес в областях, применение в которых изначально не подразумевалось. В частности система была опробована, как инструмент для проведения дистанционного обучения.
1.4. Апробация
Основные результаты работы докладывались на двух конференциях в МИЭМ и в МППГУ, на которых проводилось практическое представление системы.
1.5. Завершенность
Система работает с февраля 2011 и успешно показала себя в эксплуатации.
1.6. Структура и объем работы
Пояснительная записка состоит из 63 страниц и содержит 9 частей:
1. Введение;
2. Постановка задачи;
3. Обзорно-аналитическая часть;
4. Технологическая часть;
5. Разработка;
6. Экспериментальная часть;
7. Охрана труда;
8. Заключение;
9. Список публикаций.
2. Постановка задачи
2.1. Задачи на исследование
· Провести анализ существующих решений в области видеовзаимодействия;
· Провести обзор технологических решений для разработки RIA;
· Выбрать платформу для разработки;
· Выбрать сервер для построения системы.
2.2. Задачи на разработку
Разработать клиентскую часть платформы видеовзаимодействия Viditory, состоящую из следующих элементов:
· Зрительского представления;
· Редактора шаблонов;
· Воспроизведения записи.
Разрабатываемая система не должна нуждаться в дополнительном оборудовании и должна работать на основных существующих операционных системах.
3. Обзорно-аналитическая часть
3.1. Анализ существующих решений в области видеовзаимодействия
Основную роль в видеовзаимодействие играет передача аудио и видео потоков. Для этой цели существует два варианта:
1. Использование плагинов, дополнительных расширений для браузеров.
2. Использование встроенных возможностей браузера.
В качестве плагинов можно использовать следующие технологии: Windows Media Player, QuickTime, Flash, Silverlight, Java. Каждая из этих технологий позволяет передавать аудио и видео контент. Но для разработки платформы требуется технология предоставляющая средства для разработки интерфейса пользователя и передачи дополнительной информации. Поэтому из представленного списка плагинов остаются только Flash, Silverlight, Java.
В качестве встроенных возможностей браузера для передачи видео можно использовать последнюю версию языка разметки HTML 5.
3.2. Обзор технологических решений для разработки RIA
Разрабатываемая платформа видеовзаимодействия представляет собой полноценный веб-сервис или Rich Internet Application (RIA). RIA – это веб-приложение, которое имеет все возможности характерные для декстопных приложений.
Термин RIA был впервые представлен в 2002 году в докладе компании Macromedia, которая сейчас присоединена к Adobe.
«Интернет 2002 года будет другим. Конечные пользователи и бизнес ожидают большего от своих инвестиций в Интернет технологии. Необходимость доставлять актуальные данные пользователю заставляет компании обратить свое внимание на более современные модели Интернет приложений; модели, которые сочетают в себе богатое мультимедиа содержимое традиционных настольных приложений с возможностями размещения и содержимым веб-приложений. Компании также предвосхищают рост использования веб-сервисов и смотрят в мир, где приложения должны работать на различных устройствах. Эти тенденции ведут индустрию к новому поколению клиентских приложений».
Перевод Macromedia Flash MX—A next-generation rich client [1]
Вот главные аспекты, на которых основывается концепция RIA:
· Предоставление эффективной, высокопроизводительной среды для выполнения кода, контента и коммуникаций. Принцип состоит в том, что опыт работы конечного пользователя с веб-приложениями, основанными на чистом HTML, страдает от различных проблем, связанных с производительностью. Это включает в себя использование модели «запрос-ответ» при отображении веб-страниц, необходимость динамически генерировать большие блоки текстовой информации для передачи простых данных, отсутствие хранения данных на стороне клиента, невозможность легко использовать удаленную бизнес-логику.
· Интеграция контента, коммуникаций и интерфейсов приложений в общую среду.
· Предоставление возможности быстрой разработки приложений с использованием компонент в среде разработки.
· Использование веб-сервисов, предоставляемых сервером. Должно существовать четкое разделение логики и пользовательского интерфейса от логики приложения размещаемого в Интернет.
· Приложение должно быть доступно как он-лайн, так и офф-лайн клиентам.
· Возможность распространения приложения на различных платформах и устройствах. Приложения должны поддерживаться на всех популярных настольных системах, а также для всех быстро развивающихся устройств, таких как смартфоны, планшетные компьютеры, игровые консоли, телевизионные приставки и так далее.
· Для разработки RIA существует нескольких основных платформ: Adobe Flash, Java, Microsoft Silverlight, HTML 5 и JavaScript.
3.2.1 Adobe Flash Platform
Adobe Flash Platform – это мультимедиа платформа, которая представляет собой набор интегрированных технологий. Flash манипулирует векторной и растровой графикой для анимации текста, рисования и статичных изображений. Поддерживает потоковое аудио и видео и может получать ввод данных с клавиатуры, мыши, микрофона и камеры. Разработка для данной платформы ведется с помощью языка разметки MXML и объектно-ориентированного языка ActionScript.
3.2.2 Java applet
Java applet – это приложение, доступ к которому конечный пользователь получает через веб-браузер с иcпользованием Java Virtual Machine, выполняющей Java байт-код. Java applet обычно пишутся на языке программирования Java, но могут быть также написаны на других языках, которые компилируются в Java байт-код, например Jython, JRuby. В приложение может быть использована поддержка 3D аппаратного ускорения, которая доступна из Java. Это делает Java applet хорошо подходящими для нетривиальных вычислений и интенсивной визуализации.
3.2.3 Microsoft Silverlight
Microsoft Silverlight – это мощное средство для разработки и доставки RIA и мультимедиа контента в Интернет. Эта технология также поддерживает потоковое вещание, мультимедиа, графику и анимацию. Разработку приложений для Microsoft Silverlight можно вести с помощью. Net Framework и языка разметки XAML.
3.2.4 HTML5 и JavaScript
HTML 5 – это последняя версия языка разметки HTML, который является основной технологией построения веб-страниц в Интернет. В нем появились возможности встраивать в страницу видео и аудио, использовать canvas (предназначены для создания растрового изображения с помощью JavaScript) и интегрировать SVG графику. Так как HTML поддерживается браузерами по умолчанию, то это позволяет передавать мультимедиа и графическое содержимое в Интернет без использования сторонних плагинов.
JavaScript – это язык программирования, встроенный в браузеры и предоставляющий возможность разрабатывать улучшенные пользовательские интерфейсы и динамические веб-страницы.
3.3. Выбор платформы для разработки
Как видно из таблицы 1, все платформы предоставляют функционал необходимый для разработки приложения. На изображении 1 видно, что по распространенности среди плагинов лидирует Adobe Flash.
Если сравнивать Adobe Flash Platform с HTML 5, то следует отметить, что на данном этапе не все браузеры поддерживают этот стандарт разметки веб-страниц. По этому поводу крупнейший Интернет ресурс YouTube, предоставляющий возможности видеовзаимодействия, выпустил статью, в которой подробно сравниваются эти две технологии и приводятся недостатки HTML5 [2].
На основе этих данных в качестве платформы для разработки была выбрана Adobe Flash Platform.
Таблица 1
Периферийные устройства | Потоковое аудио и видео | Графика | Кроссплатформенность | |
Adobe Flash Platform | + | + | + | + |
Microsoft Silverlight | + | + | + | - |
Java applet | + | + | + | + |
Html5 и JavaScript | +/- | +/- | + | + |
Изображение 1. Распространенность плагинов для браузеров [3].
3.4. Выбор сервера для построения системы
На основании исследования в [4] для построения первой версии системы был выбран Red 5 сервер. После запуска первой версии и тестовой эксплуатации были выявлены некоторые существенные недостатки при работе с этим сервером, такие как плохая поддержка, нестабильность, проблемы с использованием SharedObject. Поэтому для построения текущей версии системы был выбран Wowza Media Server.
4. Технологическая часть
4.1. Обзор IDE FlashDevelop
FlashDevelop [5] – это open source среда разработки, написанная на языке C#, позволяющая создавать приложения для Flash платформы. FlashDevelop использует в своей основе open source Flex SDK, предоставляемую компанией Adobe, и распространяется по MIT лицензии.
FlashDevelop обладает всеми необходимыми свойствами для разработки и отладки приложений:
· Автоматическая генерация кода (Code generation)
· Автодополнение кода (Code completion)
· Профилер (Profiler)
· Отладчик (Debugger)
· Генерация документации по коду (Code documentation)
4.2. Обзор Flex SDK
Flex SDK [6] – это высокопроизводительный open source фреймворк для разработки и поддержки веб-приложений во всех браузерах, а также разработки приложений для настольных систем. Flex SDK распространяется по лицензии MPL.
Flex предоставляет разработчику приложений для платформы Flash возможность легко создавать пользовательские интерфейсы и разрабатывать свои компоненты, используя язык разметки MXML в связке с ActionScript. Во Flex SDK входят стандартные компоненты для построения пользовательских интерфейсов, отображение которых также описывается языком MXML.
MXML [7] – это язык разметки основанный на XML. Он используется при создании пользовательских интерфейсов приложения, для описания и настройки визуальных компонентов. Во время компиляции во Flash приложение MXML преобразуется в ActionScript.
В MXML можно встраивать код ActionScript для того, чтобы обрабатывать пользовательские действия. А также использовать веб-сервисы, модальные окна, изменять состояния приложения и т. д.
4.3. Обзор взаимодействия с сервером
4.3.1. Real-Time Messaging Protocol (RTMP)
Протокол RTMP [8] разработан для высокопроизводительной передачи аудио, видео и данных между технологиями платформы Adobe Flash, в том числе Adobe Flash Player. RTMP доступен в качестве открытой спецификации для создания продуктов и технологий, которые позволяют доставлять видео, аудио и данные в открытых AMF, SWF, FLV, F4V форматах, совместимых с Adobe Flash Player.
4.3.2. Action Message Format (AMF 3)
Описание AMF
Формат AMF [9] – это компактный бинарный формат, который используется для сериализации графа объекта ActionScript. Объект в формате AMF может быть использован для сохранения и изменения состояния приложения между сессиями или для взаимодействия между приложениями и сервером через обмен строго типизированными данными.
В AMF поддерживаются 13 типов данных:
· undefined;
· null;
· Boolean (true, false);
· Численные (integer, double);
· string;
· xml, xml-doc;
· date;
· array;
· object;
· byte-array;
Использование AMF для взаимодействия с сервером [10]
Кроме сериализации ActionScript типов, AMF может быть использован в асинхронных вызовах удаленных сервисов. Простая структура сообщений используется для отправки пакета запросов к удаленному серверу.
Сообщение AMF содержит информацию об индивидуальной транзакции, которая должна быть выполнена на сервере. В нем указываются: операция на сервере, локальная операция, которая будет выполнена в случае успешного или неудачного вызова, и данные, которые будут использованы в этой операции. Структура ответного сообщения такая же, как и у отправляемого с запросом сообщения.
В первом поле сообщения AMF хранится целевой Uniform Resource Identifier (URI), который описывает: операцию, функцию или метод, вызываемый удаленно. Точный формат URI должен быть установлен в зависимости от используемой серверной реализации. Пример URI для вызова функции на сервере Wowza:
“app_instance_name/function_name”
Второе поле сообщения AMF содержит ответный URI, определяющий уникальное имя операции, которое будет использовано, чтобы сопоставить ответ с клиентским вызовом. Удаленный хост будет использовать это поле в случае ошибки. Следует отметить, что это поле требуется даже в случае, если успешный вызов на сервере не предусматривает возврата данных клиенту. Пример:
“/1”
Когда сообщение содержит ответ от удаленного сервера, целевой URI определяет метод, который должен быть вызван у локального клиента, чтобы обработать ответ. Пример:
“/1/onResult” , “/1/onStatus”
К ответному URI добавляется суффикс “/onResult”, сообщающий об успешном вызове, и суффикс “/onStatus”, сообщающий об ошибке.
Третье поле сообщения AMF содержит байт с длиной тела сообщения. Это поле может быть полезно, когда необходимо разделить AMF пакет без предварительного декодирования каждого индивидуального сообщения.
Последнее четвертое поле – это тело сообщения. Тело содержит актуальные данные, относящиеся к выполняемой операции. Если сообщение – это клиентский запрос, то тело содержит данные, отправляемые клиентом удаленному серверу для выполнения операции. Список аргументов должен быть представлен типом Strict Array. Если сообщение является ответом от сервера, то тело сообщения может содержать результат вызова удаленной операции. Также, если удаленный сервер определяет ошибку в передаваемых пользователем данных или в запрашиваемой операции, то сервер предоставит информацию об ошибке в теле ответного сообщения.
4.3.3. SharedObject
SharedObject [11] используется для хранения ограниченных объемом данных на пользовательском компьютере или на сервере. Общие объекты обеспечивают обмен данными в режиме реального времени между несколькими клиентскими SWF-файлами и объектами, которые находятся постоянно на локальном компьютере или удаленном сервере.
SharedObject используются в следующих случаях:
· Хранение локальных данных. Это самый простой способ применения общего объекта, не требующий использования сервера. Такое применение сравнимо с использованием cookie в браузере. В локальных данных можно хранить предпочитаемые настройки пользователя или сохранять нужные данные после завершения работы клиентского приложения;
· Хранение и совместное использование данных на сервере. Общий объект может хранить данные на сервере, откуда их смогут извлекать другие клиенты. Каждый раз, когда клиент вносит изменения в общий объект, исправленные данные становятся доступными всем клиентам, которые в данный момент подключены к объекту или которые подключаются к нему позднее. Если объект также имеет локальное постоянство, а клиент изменяет данные, но при этом не подключен к серверу, данные копируются в удаленный общий объект при последующем подключении пользователя к объекту;
· Совместное использование данных в режиме реального времени. Общий объект может предоставить нескольким разным клиентам доступ к данным в режиме реального времени.
Если клиент или сервер обновили удаленный SharedObject, то все пользователи, подключенные к общему объекту, автоматически получают уведомление об изменении данных в нем. Таким образом, клиентские приложения обращаются к серверу только в момент, когда нужно получить измененные данные, что существенно снижает нагрузку на сервер.
5. Разработка
5.1. Разработка архитектуры системы
5.1.1. Основные понятия
Как уже было сказано выше, вся платформа видеовзаимодействия построена на системе шаблонов. Рассмотрим подробнее понятие шаблон и связанные с ним дополнительные термины в рамках платформы Viditory.
Шаблон
Шаблон – это контейнер для объектов, в котором описываются: расположение, размер, видимость объекта, тип и имя источника.
Объект
Объект (элемент, модуль) системы – это минимальная единица, с которой взаимодействует пользователь. Объекты могут быть следующих типов: презентация, чат, видео или аудио поток. Каждый объект может быть подключен только к одному источнику данных и в зависимости от содержимого меняет свое графическое представление.
Источник
Источник – это удаленный объект на сервере, который содержит в себе все необходимые данные для объектов.
Работу с системой можно разделить на две логические составляющие:
· Проведение события в реальном времени. Сюда входят: зрительское представление, рабочее место режиссера и редактор шаблонов;
· Воспроизведение записи события.
5.1.2. Система прямого эфира
Схема взаимодействия между клиентским приложением и другими элементами системы при проведении события в режиме реального времени приведена на изображении 2.
Изображение 2. Схема системы прямого эфира.
Как видно на изображении 3, для проведения события в прямом эфире необходимо использовать Wowza Media Server, который управляет отображением информации у подключенных к системе клиентов.
5.1.3. Система записи
Взаимодействие между клиентским приложением и другими элементами системы при воспроизведении записи выглядит следующим образом:
Изображение 3. Схема системы записи.
Главное отличие в записи заключается в том, что клиенту не требуется обращаться к Wowza Media Server, а достаточно взаимодействовать с серверами, на которых хранятся уже записанные слайды презентаций, аудио и видео файлы.
5.1.4. Загрузка конфигурационного файла
Приложение на платформе Adobe Flash встраивается в страницу с использованием html кода. Для взаимодействия между html и flash приложением используются flashvars. Flashvars – это переменные, значения которых указываются в embed коде для вставки flash приложений в html страницу. Пример вставки swf в html страницу с использованием SWFObject:
<script type="text/javascript">
var flashvars = {};
flashvars. configUrl = http://dev. *****/as3/event/100.xml";
var params = {};
var attributes = {};
swfobject. embedSWF("untitled. swf", "myAlternativeContent", "800", "600", "9.0.0", false, flashvars, params, attributes);
</script>
В качестве параметра во flash приложение передается ссылка на конфигурационный файл в формате xml, который загружается с сервера обычным HTTP-запросом.
5.2. Разработка среды управления событием в режиме реального времени
5.2.1. Авторизация
Одной из главных задач во время работы с системой в режиме реального времени является авторизация клиента. Следует отметить, что в данном случае стоит различать авторизацию пользователя непосредственно на сервисе и авторизацию пользователя во flash приложении.
Пример конфигурационного файла с параметрами для подключения к мультимедиа серверу Wowza Media Server и для последующей авторизации клиентского flash приложения:
<record>
<server>172.27.2.77/viditory/</server>
<group>usergroup_If9qjYdvMTQLqUmE6VIGAH05XdQwNFvtVFUdB6Jm4x6ops0wlJaWpa2koPR9tkDn</group>
<event>event-100-SJT2QKNNxlV47Sk4O96z6hSaXs9sw9mL</event>
<authType>key</authType>
<authUrl>http://dev. *****/as3/key. xml</authUrl>
<editorLink>http://dev. *****/event/editor/id/100</editorLink>
</record>
После загрузки конфигурационного файла flash приложение использует поле authUrl, в котором содержится ссылка на xml файл с параметрами сессии пользователя. Flash приложение загружает xml файл, который выглядит следующим образом:
<session>
<id>16797</id>
<key>ab1Wi2URCu10b4I4SNPZ6UR</key>
</session>
Если пользователь авторизован на сервисе, то в поле key содержится ключ, используемый для авторизации flash приложения. Если пользователь не авторизован, то поле будет пустым.
После получения информации о сессии приложение создает RTMP подключение с сервером, где адрес сервера формируется с использование полей server и group из основного файла, а в качестве параметров при подключении передается тип авторизации authType и параметры сессии id и key.
Использование такой схемы авторизации позволяет защитить систему от несанкционированного доступа и разграничить права пользователей системы.
5.2.2. Права пользователей
Пользователи системы делятся по правам доступа к событию на следующие категории:
· Редакторы события. Имеют полный доступ к управлению событием: редактирование и переключение шаблонов, управление титрами, управление правами доступа в чате, создание источников для передачи аудио и видео потоков;
· Участники события. Пользователи, приглашенные редактором для участия в событии. Могут передавать аудио и видео, если для них созданы источники;
· Приглашенные для участия в событии внешние пользователи. К этой категории относятся пользователи, незарегистрированные на сервисе, но при этом имеющие право вещать аудио и видео потоки в случае, если редактор события создал для них соответствующие источники;
· Зарегистрированные на сервисе пользователи, но не являющиеся непосредственными участниками события;
· Незарегистрированные на сервисе пользователи.
Клиентское приложение получает информацию о категории пользователя, подключенного к системе следующим образом:
После успешного подключения клиентского приложения к серверу, на сервере вызывается удаленная команда “getMyUserRole”;
Приложение ожидает ответа на запрос;
В случае успешного ответа приложение получает сообщение с информацией о правах доступа пользователя. В случае ошибки приложение повторяет свой запрос.
Разделение пользователей на категории позволяет контролировать доступ к дополнительным возможностям по редактированию и управлению событием.
5.2.6. Формат основного удаленного общего объекта
Информацию о каждом событие, проходящем в режиме реального времени, клиентское приложение получает из удаленного общего объекта. После авторизации и получения прав пользователя приложение подключается к объекту с именем из конфигурационного файла в поле “event”. Рассмотрим формат этого объекта:
name:String;
title:String;
sources:Array;
templates:Array;
layouts:Array;
currentTemplate:int;
recording:Boolean;
state:Enum [FUTURE, ONAIR, PAUSE, FINISHED];
В поле name содержится системное имя объекта, которое было присвоено сервером. В следующем поле содержится имя события, которое было задано редактором. В поле sources содержится массив объектов Source, в templates – массив Template, в layouts – массив Layout. Каждому шаблону при добавлении в базу данных присваивается уникальный идентификационный номер, по которому к ним и происходит обращение, поле currentTemplate содержит номер текущего активного шаблона. В “recording” записано true, если событие записывается и false, если нет. И в последнем поле хранится статус события. Само событие имеет четыре различных статуса:
FUTURE – событие ещё не началось;
ONAIR – событие идет;
PAUSE – событие приостановлено;
FINISHED – событие завершено и доступна запись.
Объект “Source” отражает информацию об источнике для объекта и хранит в себе: имя, присвоенное сервером, заголовок, присвоенный пользователем при создании источника и тип источника. В зависимости от типа источник хранит в себе разные данные, поэтому объекты в системе имеют различное поведение.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 |
