600 lignes de code pour développer le serveur RTSP le plus simple de l'histoire (pure syntaxe native du langage GO)

1. Introduction

Le serveur RTSP open source sur le marché est trop compliqué Aujourd'hui, nous utilisons le langage GO pour développer le serveur de diffusion en direct RTSP le plus simple de l'histoire, sans compter sur un framework de langage GO tiers, en utilisant le langage GO natif.

En parlant de protocole vidéo en direct, au début, l'auteur a utilisé la solution ffmpeg + nginx (RTMP), mais il y a un problème avec le module RTMP nginx. Il faut au moins six ou sept secondes pour afficher l'image. Je ne le fais pas. t savoir s'il s'agit du problème du protocole RTMP ou du problème du module nginx rtmp. Au bout d'un moment, j'utiliserai le langage go pour lire un serveur RTMP.

En raison des lacunes ci-dessus de ffmpeg + nginx, je me suis tourné vers la solution de serveur RTSP d'EasyDarwin, qui est la solution ffmpeg + EasyDarwin (RTSP). En revanche, RTSP peut afficher des images en deux secondes, ce qui est au-delà de mes attentes.

Après un certain temps, j'ai trouvé qu'EasyDarwin avait également quelques lacunes. Parce que j'ai besoin d'une authentification, d'un rappel push, d'un rappel de lecture, et il semble qu'EasyDarwin n'indique pas s'il est disponible dans le commerce sur github, il y a donc certains risques à utiliser EasyDarwin.

En résumé, j'ai décidé de développer mon propre serveur RTSP, le langage préféré est bien sûr le langage GO, et j'ai décidé de ne référencer aucun framework tiers et d'utiliser GO natif.

En fait, je pense que le flash a été abandonné et que le protocole RTMP correspondant devrait également être abandonné. Le délai de lecture RTMP est élevé et la vitesse d'ouverture est lente. En revanche, le protocole RTSP a un délai de moins de 1 seconde, et la vitesse d'ouverture est super rapide.

2. RTSP

En parlant de RTSP, je dois parler de RTP (Real-time Transport Protocol), RTP est utilisé pour transmettre des données de trame vidéo. Cependant, dans de nombreux scénarios, nous devons effectuer d'autres interactions avec le serveur, telles que le contrôle de la transmission RTP, puis le protocole RTSP est né. RTSP est similaire au protocole HTTP. Avant la transmission de la trame vidéo RTP, le deux parties interagissent d'abord avec le protocole RTSP Le protocole RTSP Une fois l'interaction terminée, l'extrémité de diffusion en continu envoie en continu des trames vidéo RTP au serveur RTSP et l'extrémité de diffusion attend que le serveur RTSP envoie des images vidéo RTP.

Dans l'analyse finale, protocole RTSP = données RTSP (protocole de chaîne, similaire à HTTP) + données RTP (protocole binaire), où les données RTP sont transmises telles quelles, et les données RTP poussées par l'extrémité de diffusion en continu sont transmises à la section de lecture comme c'est le cas par le serveur. La différence est que la fin du streaming et la fin de la lecture doivent d'abord utiliser le protocole RTSP pour interagir avec le serveur pendant plusieurs tours.Une fois l'interaction terminée, c'est au tour des données binaires RTP.

Nous ne considérons pas que RTSP utilise le protocole UDP ici. J'ai testé dans d'autres articles. UDP est très facile à perdre des cadres, et il est facile à filtrer, et il est trop restreint. Par conséquent, nous considérons uniquement le Protocole RTSP ici.

Le responsable du RTSP a donné trop de commandes, nous ne considérons pas ici à la demande, uniquement la diffusion en direct.

Pour un système de diffusion en direct RTSP complet, il existe Pusher, Server et Player.

3. Pousser l'extrémité

Le flux de travail de l'extrémité de poussée est le suivant:

3.1 OPTIONS

          L'extrémité de poussée envoie:

       

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

Il convient de noter que \ n est le caractère de retour chariot, que j'ai marqué spécialement, je n'afficherai pas le caractère retour chariot ci-dessous, et il doit y avoir un caractère retour chariot pour les sauts de ligne.

        Réponse RTSP:

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

Dans le message de réponse, la session est générée par le serveur RTSP à ce moment, et cette session est utilisée tout au long du cycle de connexion de l'extrémité push.

3.2 ANNONCE

       L'extrémité de poussée envoie:

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

Une fois que le serveur RTSP a reçu ce message, il doit enregistrer le texte de "v = 0" jusqu'à la fin, car il s'agit du message sdp de ce canal RTSP. Ceci est nécessaire lorsque le lecteur demande des données.

Le serveur RTSP envoie:

RTSP/1.0 200 OK
CSeq: 2
Session: ZTnZlWLGg

3.3 CONFIGURATION 

   L'extrémité de poussée envoie:

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

Le serveur RTSP a répondu:

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

3.4 ENREGISTREMENT

L'extrémité de poussée envoie:

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

Le serveur RTSP a répondu:

RTSP/1.0 200 OK
CSeq: 4
Session: ZTnZLWlGg

3.5 Message RTP

À ce stade, l'extrémité de transmission commence à envoyer des messages RTP en continu et le serveur RTSP n'a besoin que de transmettre les messages RTP à la fin de lecture sans répondre aux messages de fin de transmission.

4. Joueur

Le processus du joueur:

4.1 OPTIONS 

Le joueur envoie:

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

Le serveur RTSP répond: La session du lecteur est générée par le serveur RTSP à ce moment, et reste inchangée pendant la période de connexion du lecteur

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

4.2 DÉCRIRE

Le joueur envoie:

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

Rappelez-vous en 3.2, laissez le message sdp sauvegardé être envoyé au joueur à ce moment.

Le serveur RTSP a répondu:

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 CONFIGURATION

   Le joueur envoie:

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

Le serveur RTSP a répondu:

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

4.4 JOUER

Le joueur envoie:

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

Le serveur RTSP a répondu:

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

4.5 Message RTP

Ensuite, le serveur RTSP n'a besoin que d'envoyer le message RTP reçu en 3.5 au lecteur intact.

5. Image d'effet

      5.1 Serveur

      

5.2 Bout poussoir ffmpeg

    5.3 Joueur

6. Code

Slam ici et entrez dans le nuage de code