600 строк кода для разработки самого простого RTSP-сервера в истории (чистый собственный синтаксис языка GO)

1. Введение

RTSP-сервер с открытым исходным кодом, представленный на рынке, слишком сложен. Сегодня мы используем язык GO для разработки самого простого в истории сервера прямой трансляции RTSP, не полагаясь на какую-либо стороннюю языковую структуру GO, используя собственный язык GO.

Говоря о протоколе живого видео, вначале автор использовал решение ffmpeg + nginx (RTMP), но есть проблема с модулем nginx RTMP. Отображение изображения занимает не менее шести или семи секунд. Не знаю, проблема ли это в протоколе RTMP или в модуле nginx rtmp. Через некоторое время я буду использовать язык go для игры на RTMP-сервере.

Из-за вышеупомянутых недостатков ffmpeg + nginx я обратился к решению EasyDarwin для сервера RTSP, которое представляет собой решение ffmpeg + EasyDarwin (RTSP). Напротив, RTSP может отображать изображения в течение двух секунд, что превосходит мои ожидания.

Через некоторое время я обнаружил, что EasyDarwin также имеет некоторые недостатки. Поскольку мне нужна аутентификация, обратный вызов push, обратный вызов воспроизведения, и кажется, что EasyDarwin не указывает, доступен ли он в продаже на github, поэтому есть определенные риски при использовании EasyDarwin.

Таким образом, я решил разработать свой собственный сервер RTSP.Предпочтительным языком, конечно же, является язык GO, и я решил не ссылаться на какие-либо сторонние фреймворки и использовать собственный GO.

Фактически, я думаю, что от флэш-памяти отказались, и от соответствующего протокола RTMP также следует отказаться. Задержка воспроизведения RTMP высокая, а скорость открытия медленная. Напротив, протокол RTSP имеет задержку менее 1 секунды и скорость открытия супер быстрая.

2. RTSP

Говоря о RTSP, я должен сказать о RTP (транспортном протоколе в реальном времени), RTP используется для передачи данных видеокадров. Однако во многих сценариях нам необходимо выполнить некоторые другие взаимодействия с сервером, такие как управление передачей RTP, и затем родился протокол RTSP. RTSP аналогичен протоколу HTTP. Перед передачей видеокадра RTP две стороны сначала взаимодействуют с протоколом RTSP Протокол RTSP После завершения взаимодействия сторона потоковой передачи непрерывно отправляет видеокадры RTP на сервер RTSP, а сторона потоковой передачи ожидает, пока сервер RTSP отправит видеокадры RTP.

В конечном итоге протокол RTSP = RTSP (строковый протокол, аналогичный HTTP) данные + данные RTP (двоичный протокол), где данные RTP пересылаются как есть, а данные RTP, отправленные концом потоковой передачи, направляются в секцию воспроизведения. как на сервере. Разница в том, что конец потоковой передачи и конец воспроизведения должны сначала использовать протокол RTSP для взаимодействия с сервером в течение нескольких раундов.После завершения взаимодействия наступает очередь двоичных данных RTP.

Мы не рассматриваем RTSP для использования протокола UDP. Я тестировал в других статьях. UDP очень легко теряет кадры, его легко отсеять, и он слишком ограничен. Поэтому мы рассматриваем только протокол на основе TCP Протокол RTSP здесь.

Чиновник RTSP дал слишком много команд, мы здесь не рассматриваем on-demand, только прямую трансляцию.

Для полноценной системы прямой трансляции RTSP есть Pusher, Server и Player.

3. Толкать конец

Рабочий процесс толкающего конца следующий:

3.1 ОПЦИИ

          Push-конец отправляет:

       

OPTIONS rtsp://192.168.1.201:5545/2_1 RTSP/1.0\nCSeq: 1\nUser-Agent: Lavf58.37.100\n\n

Следует отметить, что \ n - это символ возврата каретки, который я выделил специально, я не буду отображать символ возврата каретки ниже, а для разрывов строк должен быть символ возврата каретки.

        Ответ RTSP:

RTSP/1.0 200 OK
CSeq: 1
Session: ZTnZLWlGg
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD

В ответном сообщении сеанс генерируется сервером RTSP в это время, и этот сеанс используется на протяжении всего цикла соединения на стороне push.

3.2 ОБЪЯВЛЕНИЕ

       Push-конец отправляет:

ANNOUNCE rtsp://192.168.1.201:5545/2_1 RTSP/1.0
Content-Type: application/sdp
CSeq: 2
User-Agent: Lavf58.37.100
Session: ZTnZLWlGg
Content-Length: 296

v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 192.168.1.201
t=0 0
a=tool:libavformat 58.37.100
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z00AKp2oHgCJ+WbgICAoAAADAAgAAAMBlCA=,aO48gA==; profile-level-id=4D002A
a=control:streamid=0

После того, как RTSP-сервер получит это сообщение, ему необходимо сохранить текст от «v = 0» до конца, потому что это sdp-сообщение этого RTSP-канала. Это необходимо, когда игрок запрашивает данные.

Сервер RTSP отправляет:

RTSP/1.0 200 OK
CSeq: 2
Session: ZTnZlWLGg

3.3 НАСТРОЙКА 

   Push-конец отправляет:

SETUP rtsp://192.168.1.201:5545/2_1/streamid=0 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record
CSeq: 3
User-Agent: Lavf58.37.100
Session: ZTnZLWlGg

Сервер RTSP ответил:

RTSP/1.0 200 OK
CSeq: 3
Session: ZTnZLWlGg
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record

3.4 ЗАПИСЬ

Push-конец отправляет:

RECORD rtsp://192.168.1.201:5545/2_1 RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent: Lavf58.37.100
Session: ZTnZLWlGg

Сервер RTSP ответил:

RTSP/1.0 200 OK
CSeq: 4
Session: ZTnZLWlGg

3.5 сообщение RTP

На этом этапе push-конец начинает непрерывно отправлять сообщения RTP, и серверу RTSP нужно только пересылать сообщения RTP в конец воспроизведения, не отвечая на сообщения push-end.

4. Игрок

Процесс игрока:

4.1 ОПЦИИ 

Игрок отправляет:

OPTIONS rtsp://192.168.1.201:5545/2_1 RTSP/1.0
CSeq: 1
User-Agent: Lavf58.37.100

Сервер RTSP отвечает: сеанс плеера генерируется сервером RTSP в это время и остается неизменным в течение периода соединения плеера.

RTSP/1.0 200 OK
CSeq: 1
Session: YXN_wZ_GR
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD

4.2 ОПИСАНИЕ

Игрок отправляет:

DESCRIBE rtsp://192.168.1.201:5545/2_1 RTSP/1.0
Accept: application/sdp
CSeq: 2
User-Agent: Lavf58.12.100
Session: YXN_wZ_GR

Помните, что в 3.2, пусть сохраненное сообщение sdp будет отправлено игроку в этот момент.

Сервер RTSP ответил:

RTSP/1.0 200 OK
Session: YXN_wZ_GR
Content-Length: 296
CSeq: 2

v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 192.168.1.201
t=0 0
a=tool:libavformat 58.37.100
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z00AKp2oHgCJ+WbgICAoAAADAAgAAAMBlCA=,aO48gA==; profile-level-id=4D002A
a=control:streamid=0

4.3 НАСТРОЙКА

   Игрок отправляет:

SETUP rtsp://192.168.1.201:5545/2_1/streamid=0 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record
CSeq: 3
User-Agent: Lavf58.37.100
Session: YXN_wZ_GR

Сервер RTSP ответил:

RTSP/1.0 200 OK
CSeq: 3
Session: YXN_wZ_GR
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record

4.4 ИГРАТЬ

Игрок отправляет:

PLAY rtsp://192.168.1.201:5545/2_1 RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent: Lavf58.12.100
Session: YXN_wZ_GR

Сервер RTSP ответил:

RTSP/1.0 200 OK
Session: YXN_wZ_GR
Range: npt=0.000-
CSeq: 4

4.5 сообщение RTP

Затем серверу RTSP нужно только отправить RTP-сообщение, полученное в 3.5, плееру без изменений.

5. Эффект изображения

      5.1 Сервер

      

5.2 толкающий конец ffmpeg

    5.3 Игрок

6. Код

Захлопните здесь и войдите в облако кода