0% нашли этот документ полезным (0 голосов)
4 просмотров6 страниц

Socket6 VideoStreaming

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

Загружено:

dimamoiseinko267
Авторское право
© All Rights Reserved
Мы серьезно относимся к защите прав на контент. Если вы подозреваете, что это ваш контент, заявите об этом здесь.
Доступные форматы
Скачать в формате PDF, TXT или читать онлайн в Scribd
0% нашли этот документ полезным (0 голосов)
4 просмотров6 страниц

Socket6 VideoStreaming

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

Загружено:

dimamoiseinko267
Авторское право
© All Rights Reserved
Мы серьезно относимся к защите прав на контент. Если вы подозреваете, что это ваш контент, заявите об этом здесь.
Доступные форматы
Скачать в формате PDF, TXT или читать онлайн в Scribd

Задача по программированию сокетов 6: потоковое

видеовещание с помощью RTSP и RTP


В этой лабораторной вы реализуете сервер и клиент для потокового вещания видео,
которые будут взаимодействовать при помощи потокового протокола реального времени
(Real-Time Streaming Protocol, RTSP) и передавать данные с использованием протокола
реального времени (RTP). Ваша задача заключается в реализации протокола RTSP на
клиенте и RTP-пакетирования на сервере.
Вам будет предоставлен код, который реализует протокол RTSP на серверной стороне и
механизм депакетирования с помощью RTP на клиенте. Он также отвечает за вывод
переданных видеоданных.

Код
Client, ClientLauncher
Модуль ClientLauncher запускает Client и пользовательский интерфейс, который
используется для отправки команд RTSP и для отображения видео. В классе Client вам
необходимо будет реализовать действия, выполняемые при нажатии кнопок. Вносить
изменения в модуль ClientLauncher не нужно.
SeverWorker, Server
Эти два модуля реализуют сервер, который отвечает на запросы RTSP и возвращает поток
видеоданных. Взаимодействие через RTSP уже реализовано, и для пакетирования данных
видеопотока ServerWorker вызывает методы класса RtpPacket. Вам не нужно изменять эти
модули.
RtpPacket
Этот класс используется для обработки пакетов RTP. Он включает отдельные методы для
обработки полученных на стороне клиента пакетов, и вам эти методы изменять не нужно.
Метод Client также депакетирует (декодирует) данные, и вам тоже его менять не
требуется. Вам необходимо будет завершить реализацию RTP-пакетирования
видеоданных (которая используется сервером).
VideoStream
Этот класс используется для чтения видеоданных из файла на диске. Его менять не нужно.

Запуск приложения
После того, как вы завершите написание кода программы, можете запустить ее:
Сначала запустите сервер, используя команду
python [Link] порт-сервера
где порт-сервера – это порт, по которому ваш сервер слушает входящие RTSP-
соединения. Стандартный номер порта для этих целей 554, но вам здесь нужно выбрать
порт с номером, большим, чем 1024.
Затем запустите клиент, используя команду
python [Link] хост_сервера порт_сервера RTP_порт
видеофайл
где хост_сервера – имя компьютера, на котором запущен сервер, порт_сервера –
это порт, по которому сервер слушает, RTP_порт – порт, на который поступают RTP-
пакеты, а видеофайл – имя запрашиваемого видеофайла (у нас это файл [Link]),
формат которого описывается в приложении.
Клиент открывает соединение с сервером, и открывается следующее окно:
Нажимая кнопки в этом окне, вы отправляете RTSP-команды серверу. В нормальном
режиме клиент может выполнить следующие действия:
1. Отправить команду SETUP, которая используется для настройки сеанса и
параметров передачи.
2. Отправить команду PLAY, тем самым запустив воспроизведение видео.
3. Отправить команду PAUSE, чтобы приостановить воспроизведение.
4. Отправить команду TEARDOWN, которая завершает сеанс и закрывает
соединение.
Сервер всегда отвечает на все сообщения, которые отправляет клиент. Код 200 означает,
что запрос был обработан успешно, а коды 404 и 500 сообщают об ошибках –
FILE_NOT_FOUND (файл не найден) и connection error (ошибка соединения)
соответственно. В этой лабораторной вам нет необходимости реализовывать какие-либо
другие коды ответа сервера. Для получения более подробной информации о протоколе
RTSP обратитесь к документу RFC 2326.

Клиент
Ваша первая задача заключается в реализации протокола RTSP на стороне клиента. Чтобы
сделать это, необходимо завершить написание тех функций, которые вызываются при
нажатии кнопок пользовательского интерфейса. Вам нужно будет реализовать действия
для следующих типов запросов.
При запуске клиента он также открывает RTSP-сокет для связи с сервером. Используйте
этот сокет для отправки всех RTSP-запросов.
SETUP
 Отправляем SETUP-запрос серверу. В него необходимо добавить транспортный
заголовок, в котором будет указан номер порта для созданного сокета RTP-данных.
 Читаем ответ сервера и анализируем заголовок сеанса для получения
идентификатора сеанса RTSP.
 Создаем датаграммный сокет для получения RTP-данных и устанавливаем
значение тайм-аута на сокете, равное 0,5 секунды.
PLAY
 Отправляем PLAY-запрос серверу. В него необходимо добавить заголовок сеанса с
идентификатором, полученным в ответе на SETUP-запрос. Транспортный
заголовок сюда включать не надо.
 Читаем ответ сервера.
PAUSE
 Отправляем PAUSE-запрос серверу. В него необходимо добавить заголовок сеанса
с идентификатором, полученным в ответе на SETUP-запрос. Транспортный
заголовок сюда включать не надо.
 Читаем ответ сервера.
TEARDOWN
 Отправляем TEARDOWN-запрос серверу. В него необходимо добавить заголовок
сеанса с идентификатором, полученным в ответе на SETUP-запрос. Транспортный
заголовок сюда включать не надо.
 Читаем ответ сервера.
Примечание: Вы должны добавить заголовок CSeq в каждый отправляемый запрос.
Значение заголовка CSeq представляет собой число, которое начинается с 1 и
увеличивается на единицу для каждого следующего запроса.

Пример
Перед вами пример взаимодействия между клиентом и сервером. Запросы клиента
обозначены как К:, а ответы сервера – С:. В этой лабораторной клиент и сервер не
используют сложные методы синтаксического анализа, и подразумевается, что поля
заголовка следуют в определенном порядке, как вы видите ниже.
К: SETUP [Link] RTSP/1.0
К: CSeq: 1
К: Transport: RTP/UDP; client_port= 25000

С: RTSP/1.0 200 OK
С: CSeq: 1
С: Session: 123456

К: PLAY [Link] RTSP/1.0


К: CSeq: 2
К: Session: 123456

С: RTSP/1.0 200 OK
С: CSeq: 2
С: Session: 123456

К: PAUSE [Link] RTSP/1.0


К: CSeq: 3
К: Session: 123456

С: RTSP/1.0 200 OK
С: CSeq: 3
С: Session: 123456

К: PLAY [Link] RTSP/1.0


К: CSeq: 4
К: Session: 123456

С: RTSP/1.0 200 OK
С: CSeq: 4
С: Session: 123456

К: TEARDOWN [Link] RTSP/1.0


К: CSeq: 5
К: Session: 123456

С: RTSP/1.0 200 OK
С: CSeq: 5
С: Session: 123456

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

Сервер
На стороне сервера вам нужно будет реализовать пакетирование видеоданных в RTP-
пакеты. Вам необходимо создать пакет, установить поля в заголовке пакета и скопировать
данные (то есть, один видеокадр) в пакет.
Когда сервер получает PLAY-запрос от клиента, сервер читает один кадр видео из файла и
создает объект RtpPacket, который является RTP-инкапсуляцией видеокадра. Затем
каждые 50 миллисекунд он отправляет кадр клиенту, используя протокол UDP.
Для инкапсуляции сервер вызывает функцию кодирования класса RtpPacket. Ваша задача
– написать эту функцию. Вам нужно будет сделать следующее: (буквы в скобках
относятся к полям в формате RTP-пакетов, представленным ниже).
 Установить значение поля (V) версии RTP. Устанавливаем равным 2.
 Установить значение полей: (P) – для набивки (padding), (X) – для расширений
протокола (extension), (CC) – для количества CSRC-идентификаторов и маркера
(M). В нашем случае все они равны нулю.
 Установить значение поля (PT) полезной нагрузки (payload). В данном случае
значение 26, которое соответствует формату MJPEG.
 Установить номер последовательности. Сервер отдает этот номер в качестве
аргумента frameNbr для функции кодирования.
 Установить временной штамп, используя модуль для работы со временем.
 Установит идентификатор источника (SSRC). Можете выбрать любое целое число,
оно будет идентифицировать сервер.
 Поскольку источник один (нет других участников, вносящих вклад в общий поток,
то есть СС==0), то поля CSRC не будет, и размер заголовка пакета будет занимать
12 байт, а именно 3 первые строки на диаграмме, представленной ниже.
Вы должны заполнить поля заголовка в байтовом массиве header класса RtpPacket. Вам
также будет необходимо скопировать полезную нагрузку (заданную в качестве аргумента
data), в поле данных payload класса RtpPacket.
Вышеприведенная схема использует сетевой порядок байт, известный также как big-
endian (порядок от старшего к младшему). В языке Python используется тот же порядок
байт, так что вам ничего менять не нужно.
Для получения более подробной информации о протоколе RTP смотрите документ RFC
1889.

Играем с битами
Ниже даны некоторые примеры установки и проверки отдельных битов или их групп.
Следует отметить, что в формате заголовка пакета RTP меньшие битовые номера
относятся к более высоким разрядам, то есть бит с номером 0 в байте равен 2^7, а бит с
номером 7 равен 1 (или 2^0). В приведенных ниже примерах номера битов соответствуют
числам на диаграмме, представленной выше.
Так как поле заголовка в классе RtpPacket является байтовым массивом, вам нужно будет
задавать его сразу одним байтом, то есть группами по 8 бит – в первом байте биты 0-7, во
втором 8-15 и т.д.
Чтобы установить в единицу бит с номером n переменной mybyte, имеющей тип byte:
mybyte = mybyte | 1 << (7 - n)
Чтобы установить биты переменной mybyte с номерами n и n+1 в значение foo:
mybyte = mybyte | foo << (7 - n)
При этом foo должна иметь значение, которое можно выразить двумя битами, то есть 0,1,2
или 3.
Чтобы скопировать 16-битное целое foo в две переменных типа byte:
b1 = (foo>>8) & 0xFF
b2 = foo & 0xFF
После этого b1 будет содержать 8 верхних разрядов переменной foo, а b2 – 8 нижних.
Аналогично можно скопировать 32-битное целое в 4 байта.

Пример установки битов


Предположим, нам нужно заполнить первый байт заголовка RTP-пакета следующими
значениями:
V=2
P=0
X=0
CC = 3
В двоичном виде это будет выглядеть так
10|0|0|0011
V=2 P X CC=3
2^7.............2^0

Дополнительные упражнения
1. Рассчитайте статистику сеанса. Для этого вычислите коэффициент потери пакетов
RTP, скорость видеопотока (в битах или байтах в секунду), а также любые другие
интересующие вас статистические показатели.
2. В пользовательском интерфейсе клиентской программы есть 4 кнопки для 4
различных действий. Если вы посмотрите на стандартные медиа-плееры, например,
RealPlayer или Windows Media Player, вы можете увидеть, что у них есть только 3
кнопки: PLAY (воспроизведение), PAUSE (пауза), и STOP (что примерно
соответствует TEARDOWN), а кнопка SETUP (настройки) пользователю
недоступна. Если предположить, что такая кнопка настройки обязательна для
RTSP-взаимодействия, как бы вы реализовали ее в медиа-плеере? Когда клиент
должен отправлять команду SETUP? Придумайте решение и реализуйте его. Кроме
того, подумайте, подойдет ли использование команды TEARDOWN для обработки
нажатия на кнопку STOP?
3. В текущей версии клиентской и серверной программ реализован только
минимально необходимый функционал взаимодействия через RTSP, а также
команда PAUSE. Разработайте метод DESCRIBE, который бы использовался для
передачи информации о медиапотоке. Когда сервер получает DESCRIBE-запрос,
он отправляет в ответ файл с описанием сеанса, в котором клиенту сообщается
информация о характеристиках медиапотоков и об используемых параметрах их
кодирования.

Приложение
1. Проприетарный формат MJPEG (Motion JPEG)
В этой лабораторной работе сервер генерирует потоковое видео, которое было
закодировано в файл проприетарного формата MJPEG. Этот формат сохраняет
видео как последовательно собранные JPEG- изображения, каждому из которых
предшествует 5-байтовый заголовок, который определяет размер изображения.
Сервер обрабатывает поток битов файла MJPEG, извлекая JPEG-изображения на
лету и отправляя их клиенту через определенные промежутки времени. Затем
клиент отображает отдельные JPEG-изображения по мере их поступления с
сервера.

Вам также может понравиться