2024-07-08
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
😁博客主页😁：🚀https://blog.csdn.net/wkd_007🚀
🤑博客内容🤑：🍭嵌入式开发、Linux、C语言、C 、数据结构、音视频🍭
🤣本文内容🤣：🍭介绍RTSP协议 🍭
😎金句分享😎：🍭你不能选择最好的，但最好的会来选择你——泰戈尔🍭
⏰Heure de sortie⏰ : 2024-07-06 12:22:00
Cet article ne peut pas être transmis sans autorisation ! ! !
RTSP, nom complet Real Time Streaming Protocol, le protocole de streaming en temps réel, est un protocole de couche application du système de protocole TCP/IP. Il s'agit d'une norme IETF RFC soumise par l'Université de Columbia, Netscape et RealNetworks.
Le document officiel sur le protocole RTSP est le RFC2326, lien vers le document :RFC2326-Protocole de diffusion en temps réel (RTSP)。
La syntaxe et le fonctionnement du protocole RTSP sont référencés. HTTP/1.1, un protocole basé sur du texte qui utilise le jeu de caractères ISO10646 et le codage UTF-8 ; le protocole de couche transport qui transporte RTSP est ;TCP, port par défaut554; S'il s'agit d'un tunneling RTSP-over-HTTP, le port TCP par défaut est 8080, généralement utilisé en conjonction avec le protocole RTP/RTCP, le protocole RTP transmet les données de flux en temps réel et le protocole RTCP termine la transmission des flux de données et ; commandes de contrôle.
Protocole RTP : nom complet
Real-time Transport Protocol, le protocole de transmission en temps réel, a été annoncé par le groupe de travail sur la transmission multimédia de l'IETF en 1996 dans la RFC 1889. Le protocole RTP détaille le format de paquet standard pour la diffusion audio et vidéo sur Internet. Il est construit sur le protocole UDP.
Protocole RTCP : nom complet
Real-time Transport Control Protocol, Protocole de contrôle de transport en temps réel, utilisé avec RTP. RTP utilise un port UDP pair ; RTCP utilise le port suivant de RTP, qui est un port impair. RTCP et RTP fonctionnent ensemble. RTP implémente la transmission des données réelles et RTCP est responsable de l'envoi des paquets de contrôle à toutes les personnes participant à la session. Sa fonction principale est de fournir un retour d'information sur la qualité du service fourni par RTP.
La différence entre le protocole RTSP et le protocole HTTP :
RTSP est avec état et ses commandes sont toujours envoyées dans l'ordre, et une commande peut toujours devoir être envoyée avant une autre commande. HTTP est sans état Une fois que le protocole envoie une commande, la connexion est déconnectée et il n'y a aucune dépendance entre les commandes.
Le protocole rtsp utilise le port 554 et http utilise le port 80.
Les requêtes RTSP peuvent être envoyées à la fois par le serveur et par le client, tandis que les requêtes HTTP ne peuvent être envoyées que par le client.
Les méthodes RTSP couramment utilisées incluent : OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, ANNOUNCE, GET_PARAMETER et SET_PARAMETER, etc. Les instructions d'utilisation détaillées sont les suivantes :
OPTIONS : Le client obtient du serveur la méthode prise en charge par le serveur. Cela n'affecte pas l'état du serveur ;DESCRIBE: Le client obtient du serveur la description de l'objet média spécifié par l'URL, oùAcceptLe champ spécifie le format de description ;SETUP : Le client demande au serveur d'établir une session et de préparer la transmission. Les informations de la demande comprennent principalement le protocole de transmission et le numéro de port du client ;PLAY : Le client informe activement le serveur de commencer à envoyer des données en utilisant le mécanisme spécifié par SETUP.dansRangeLe champ précise l'heure de début et de fin de lecture (la plage du flux en temps réel est généralementRange: npt=0.000-), lorsque plusieurs requêtes PLAY arrivent, le serveur mettra les requêtes PLAY en file d'attente et les exécutera séquentiellement, c'est-à-dire qu'il devra attendre la fin du premier temps PLAY avant de continuer à traiter le deuxième message PLAY.PAUSE : Le client demande que le streaming multimédia du serveur soit temporairement suspendu.capable de passerRangeLe paramètre s'arrête à un instant spécifié, ou vous pouvez spécifier un flux à mettre en pause. Par exemple, si vous spécifiez un flux audio à mettre en pause, la lecture sera silencieuse.RECORD : RECORD informe le serveur que le client va commencer à enregistrer les données multimédias selon la description précédente. danstimestamp Les champs reflètent les heures de début et de fin (UTC). Si ce champ n'est pas présent, l'heure de début ou de fin de la description du média sera utilisée. Si la session a déjà commencé, l'enregistrement démarre immédiatement.request-URI Suivant ou un autre URI. Si le serveur n'utilise pas d'URI de demande, la réponse doit être 201 (Créé) et contenir un en-tête Entité et Emplacement décrivant l'état de la demande et faisant référence à la nouvelle ressource.TEARDOWN : le client demande d'arrêter d'envoyer le flux d'URL spécifié et de libérer les ressources associées.REDIRECT : Pour rediriger une requête, le serveur informe le client qu'il doit se connecter à un autre emplacement de serveur. Il contient l'en-tête obligatoire Location, qui indique que le client doit faire une demande pour cette URL. Il peut contenir le paramètre Range, indiquant quand la redirection prendra effet. Si le client souhaite continuer à envoyer ou à recevoir des médias pour cet URI, il doit émettre une demande TEARDOWN pour la session en cours et une demande SETUP pour la nouvelle session sur l'hôte spécifié.ANNOUNCE: Lorsque le client envoie au serveur, cela signifie soumettre la description de la présentation ou l'objet média identifié par l'URL de la requête au serveur.GET_PARAMETER :GET_PARAMETER requête pour récupérer les valeurs des paramètres pour la représentation ou le flux spécifié dans l'URI. Le contenu des réponses et des réponses est laissé à la mise en œuvre. GET_PARAMETER sans corps d'entité peut être utilisé pour tester l'activité (« ping ») d'un client ou d'un serveur.SET_PARAMETER : Cette méthode demande de définir les valeurs des paramètres du flux spécifié par la démo ou l'URL. Les requêtes ne doivent contenir qu'un seul paramètre, permettant au client de décider pourquoi une requête particulière a échoué. Si la requête contient plusieurs paramètres, tous les paramètres peuvent être définis avec succès et le serveur ne doit agir que sur cette requête. Le serveur doit permettre que les paramètres soient définis à plusieurs reprises sur la même valeur, mais ne doit pas modifier la valeur du paramètre. Remarque : Les paramètres de diffusion multimédia doivent être définis à l'aide de la commande SETUP. Il est avantageux pour les pare-feu de limiter les paramètres de transfert de configuration à SETUP.Au total, 11 méthodes RTSP sont présentées ci-dessus, parmi lesquelles :SETUP、PLAY、TEARDOWN Les trois commandes sont nécessaires dans le processus RTSP et les autres méthodes ne sont pas nécessaires.etANNOUNCE、GET_PARAMETER、SET_PARAMETERLes trois commandes peuvent être envoyées du client au serveur ou du serveur au client. Les autres commandes sont envoyées du client au serveur.
RTSP a deux types de messages : les messages de demande et les messages de réponse. Le message de demande fait référence au message de demande envoyé du client au serveur et le message de réponse fait référence à la réponse du serveur au client.
Le message de requête RTSP se compose de trois parties : la ligne de requête, l'en-tête de la requête et le corps de la requête. Parmi eux, la ligne de requête est obligatoire, tandis que l'en-tête et le corps de la requête sont facultatifs en fonction de la situation spécifique.
rn)Finition.方法 : C'est la méthode RTSP introduite ci-dessus. Y compris OPTIONS, DESCRIPTION, CONFIGURATION, LECTURE, PAUSE, DÉMONTAGE, etc.请求URI: Identifie la ressource multimédia à exploiter, généralement au format rtsp://example.com/path/to/stream.协议版本: Indique la version du protocole RTSP suivie par la requête, généralementRTSP/1.0ouRTSP/2.0。OPTIONS rtsp://192.168.3.225:554/wbc RTSP/1.0
CSeq: 2
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Le message de demande RTSP se compose de trois parties : la ligne d'état, l'en-tête de réponse et le corps de la réponse. Parmi eux, la ligne d'état est obligatoire, tandis que l'en-tête de réponse et le corps de la réponse sont facultatifs en fonction de la situation spécifique.
协议版本: Indique la version du protocole RTSP suivie par la réponse, généralement RTSP/1.0 ou RTSP/2.0.状态码 : Trois chiffres, tels que : 200, 401, 500, etc., utilisés pour indiquer le résultat du traitement de la demande. Le premier chiffre représente la catégorie de réponse : 2xx indique un succès, 4xx indique une erreur client et 5xx indique une erreur serveur.状态文本: Une brève description textuelle expliquant la signification spécifique du code d'état correspondant, tel que : OK, Non autorisé, etc.RTSP/1.0 200 OK
CSeq: 2
Date: Wed, Feb 04 1970 03:25:10 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER
v=0
o=- 8913478 1 IN IP4 192.168.3.91
s=LIVE555 Streaming Media v2016.07.19
i=1080
t=0 0
a=tool:LIVE555 Streaming Media v2016.07.19
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:LIVE555 Streaming Media v2016.07.19
a=x-qt-text-inf:1080
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:5000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=64002A;sprop-parameter-sets=Z2QAKq2EAQwgCGEAQwgCGEAQwgCEO1A8ARPyoA==,aO48sA==
a=control:track1
m=audio 0 RTP/AVP 97
c=IN IP4 0.0.0.0
b=AS:768
a=rtpmap:97 PCMA/48000/2
a=control:track2
L'en-tête de réponse du message RTSP contiendra certains champs. Voici quelques champs couramment utilisés :
SETUPSélectionné dans la réponse, une fois que le client aura obtenu l'ID de session, il inclura l'ID de session dans les futurs messages de demande d'opération pour la session. Par exemple : Session : 4581E0AE timeout=65 ;
Utilisez Wireshark pour capturer les paquets réseau des médias de streaming RTSP. Vous pouvez voir que le processus général est le suivant :
1. Le client envoieOPTIONSMéthode, réponse du serveur ;
2. Le client envoieDESCRIBEMéthode, réponse du serveur ;
3. Le client envoieSETUPMéthode, réponse du serveur ;
2. Le client envoiePLAYMéthode, réponse du serveur ;
2. Le client envoieTEARDOWNMéthode, réponse du serveur ;
Le paquet de flux complet est le suivant :
OPTIONS rtsp://192.168.3.225:554/wbc RTSP/1.0
CSeq: 2
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
RTSP/1.0 200 OK
CSeq: 2
Date: Wed, Jul 03 2024 14:42:11 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER
DESCRIBE rtsp://192.168.3.225:554/wbc RTSP/1.0
CSeq: 3
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp
RTSP/1.0 200 OK
CSeq: 3
Date: Wed, Jul 03 2024 14:42:11 GMT
Content-Base: rtsp://192.168.3.225/wbc/
Content-Type: application/sdp
Content-Length: 472
v=0
o=- 1720014950032000 1 IN IP4 192.168.3.225
s=LIVE555 Streaming Media v2016.07.19
i=wbc
t=0 0
a=tool:LIVE555 Streaming Media v2016.07.19
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:LIVE555 Streaming Media v2016.07.19
a=x-qt-text-inf:wbc
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:5000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640029;sprop-parameter-sets=Z2QAKawsaoHgCJ WbgoCCgQ=,aO4xshs=
a=control:track1
SETUP rtsp://192.168.3.225/wbc/track1 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=55320-55321
RTSP/1.0 200 OK
CSeq: 4
Date: Wed, Jul 03 2024 14:42:11 GMT
Transport: RTP/AVP;unicast;destination=192.168.2.180;source=192.168.3.225;client_port=55320-55321;server_port=6970-6971
Session: 4581E0AE;timeout=65
PLAY rtsp://192.168.3.225/wbc/ RTSP/1.0
CSeq: 5
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Session: 4581E0AE
Range: npt=0.000-
RTSP/1.0 200 OK
CSeq: 5
Date: Wed, Jul 03 2024 14:42:11 GMT
Range: npt=0.000-
Session: 4581E0AE
RTP-Info: url=rtsp://192.168.3.225/wbc/track1;seq=7880;rtptime=3548171463
TEARDOWN rtsp://192.168.3.225/wbc/ RTSP/1.0
CSeq: 6
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Session: 4581E0AE
RTSP/1.0 200 OK
CSeq: 6
Date: Wed, Jul 03 2024 14:42:19 GMT
Ce qui suit analysera chaque méthode RTSP et réponse utilisée dans le message précédent.
Obtenez les méthodes disponibles sur le serveur :
Le client envoie la méthode OPTIONS et utiliseCSeq Pour spécifier le numéro de séquence de la demande, utilisezUser-Agent identifier son propre agent;
Le serveur répondra à la demande en utilisantCSeq Pour indiquer à quelle demande on répond, utilisezDatepréciser la date,PublicSpécifie la méthode fournie.
Obtenir du serveurrtsp://192.168.3.225:554/wbcune description de l'objet multimédia, oùAcceptLe champ précise le format de description :
Le client envoie la méthode DESCRIBE et utiliseCSeq Pour spécifier le numéro de séquence de la demande, utilisezUser-Agent identifiez votre mandataire,AcceptLe champ spécifie le format de description comme SDP ;
Le serveur répondra à cette requête en utilisant CSeq Pour indiquer à quelle demande on répond, utilisezDatepréciser la date,Content-TypeIndique que le type de contenu est SDP,Content-LengthSpécifiez la longueur du contenu.
Avis：
1. Pour certains nécessitant un nom d'utilisateur et un mot de passe, le serveur traitera la méthode DESCRIBE pour l'authentification. Si les informations d'authentification d'autorisation ne sont pas transmises ou si l'authentification échoue, le serveur renvoie une réponse avec le numéro d'erreur 401. Lorsque le client reçoit la réponse 401, il doit générer une autorisation basée sur les informations d'authentification de l'utilisateur connues et envoyer à nouveau une description. Si l'authentification réussit, le serveur renvoie les informations de réponse portant SDP.
2. Les informations SDP renvoyées par le serveur seront analysées dans un article ultérieur.
Le client demande au serveur d'établir une session et de préparer la transmission. Les informations de la demande comprennent principalement le protocole de transmission et le numéro de port du client ;
Le client envoie la méthode SETUP et utiliseCSeq Pour spécifier le numéro de séquence de la demande, utilisezUser-Agent identifiez votre mandataire,TransportLe champ spécifie le protocole de transmission RTP/AVP et le port acceptables (ici le port RTP est 55320 et le port RTCP est 55321) ;
Le serveur répondra à cette requête en utilisant CSeq Pour indiquer à quelle demande on répond, utilisezDatepréciser la date,TransportSpécifiez le protocole de transport RTP/AVP, l'adresse de destination, l'adresse source, le port client (RTP est 55320, RTCP est 55321), le port du serveur (RTP est 6970, RTCP est 6971),SessionSpécifiez l'ID de session.
Avis：
Dans cet exemple, RTP est transmis via le protocole UDP. Parfois, RTP sera transmis via TCP, puis.Transport Les champs varient. Cela pourrait être le suivant :
客户端请求：Transport: RTP/AVP/TCP;unicast;interleaved=0-1
服务器响应：Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=24e4e500;mode="play"
RTP/AVP/TCPIndique que le flux RTP est transmis via TCP. Lorsque cette valeur apparaît, le message n'a pas le champ client_port ;
interleaved=0-1Représente streamid, identifiant RTP streamid=0 ; RTCP streamid=1 ;
Lorsque le flux de code est transmis via TCP, il partage une liaison TCP avec RTSP, il n'a donc pas besoin d'établir une nouvelle connexion. Afin de distinguer les protocoles RTP, RTCP et RTSP, un identifiant d'en-tête doit être ajouté. Le champ d'en-tête est utilisé ici, et le tcphead est une section de quatre mots, le format est le suivant :
| magic number | channel number | embedded data length | data |
magic number: 1 octet, fixé à0x24, est un personnage$, indiquant que les données transmises ne sont pas le protocole rtsp ;
channel number: 1 octet, ID de canal, identifiant le type de flux, qui est le streamid mentionné précédemment ;
embedded data length : 2 octets, indiquant la longueur du flux
data: Indique les données du paquet RTP/RTCP
Le client informe activement le serveur de commencer à envoyer des données en utilisant le mécanisme spécifié par SETUP.
Le client envoie la méthode PLAY et utiliseCSeq Pour spécifier le numéro de séquence de la demande, utilisezUser-Agent identifiez votre mandataire,Sessionle champ spécifie l'ID de session,RangeLe champ spécifie l'heure de début et de fin de la lecture.
Le serveur répondra à cette requête en utilisant CSeq Indiquez à quelle demande il est répondu ;Datepréciser la date ;RangeLe champ spécifie l'heure de début et de fin de la lecture ;SessionLe champ spécifie l'ID de session ;RTP-InfoLe champ décrit les informations RTP du flux de code à envoyer, telles que la séquence et l'heure rtp du premier paquet RTP. Le client peut démultiplexer en fonction de ce champ.
Le client demande d'arrêter d'envoyer le flux d'URL spécifié et de libérer les ressources associées.
Le client envoie la méthode TEARDOWN et utiliseCSeq Pour spécifier le numéro de séquence de la demande, utilisezUser-Agent identifiez votre mandataire,SessionLe champ spécifie l'ID de session.
Le serveur répondra à cette requête en utilisant CSeq Indiquez à quelle demande il est répondu ;DatePrécisez la date.
Le contenu de la réponse de RTSP contient généralement un code de réponse entier à 3 chiffres et une phrase de raison. Le but de la phrase est de donner une brève description textuelle du code d'état. Le client n'a pas besoin de vérifier ou d'afficher la phrase de raison. Selon la différence entre le premier chiffre du code de réponse, il peut être divisé en cinq catégories suivantes :
Bien entendu, les codes d'erreur RTSP et les méthodes RTSP sont étroitement liés. Certaines erreurs ne peuvent être déclenchées que dans des méthodes spécifiques. Les informations détaillées sur les codes d'erreur sont les suivantes :
| code d'erreur | phrase de raison | méthode de réponse |
|---|---|---|
| 100 | Continuer | Tous |
| 200 | Succès | Tous |
| 201 | Créé | ENREGISTRER |
| 250 | Manque d'espace de stockage | ENREGISTRER |
| 300 | Choix multiples | Tous |
| 301 | Déménagé définitivement | Tous |
| 302 | Déplacé temporairement | Tous |
| 303 | Voir Autre | Tous |
| 305 | Utiliser un proxy | Tous |
| 400 | Mauvaise demande | Tous |
| 401 | Non autorisé | Tous |
| 402 | Paiement Requis | Tous |
| 403 | Interdit | Tous |
| 404 | Pas trouvé | Tous |
| 405 | Méthode Non Autorisée | Tous |
| 406 | Pas acceptable | Tous |
| 407 | Authentification proxy requise | Tous |
| 408 | Délai d'expiration de la demande | Tous |
| 410 | Disparu | Tous |
| 411 | Longueur requise | Tous |
| 412 | Échec de la condition préalable DÉCRIRE | INSTALLATION |
| 413 | Entité de demande trop grande | Tous |
| 414 | URI de requête trop longue | Tous |
| 415 | Type de média non pris en charge | Tous |
| 451 | Paramètre invalide | INSTALLATION |
| 452 | Identifiant de conférence illégal | INSTALLATION |
| 453 | Pas assez de bande passante | INSTALLATION |
| 454 | Session non trouvée | Tous |
| 455 | Méthode non valide dans cet état | Tous |
| 456 | Champ d'en-tête non valide | Tous |
| 457 | Plage non valide | JOUER |
| 458 | Le paramètre est en lecture seule | SET_PARAMETER |
| 459 | Opération d'agrégation non autorisée | Tous |
| 460 | Seules les opérations d'agrégation sont autorisées | Tous |
| 461 | Transport non pris en charge | Tous |
| 462 | Destination inaccessible | Tous |
| 500 | Erreur interne du serveur | Tous |
| 501 | Pas mis en œuvre | Tous |
| 502 | Mauvaise passerelle | Tous |
| 503 | service non disponible | Tous |
| 504 | Délai d'expiration de la passerelle | Tous |
| 505 | Version RTSP non prise en charge | Tous |
| 551 | Option non prise en charge | Tous |
如果文章有帮助的话，点赞👍、收藏⭐，支持一波，谢谢 😁😁😁
faire référence à:
Protocole de streaming en temps réel – RTSP [explication détaillée]
Maîtrisez les demandes et les réponses RTSP à partir de zéro 1
Explication détaillée du protocole multimédia de streaming RTSP
Il se consacre à la recherche technologique depuis plus de 30 ans et maîtrise divers langages tels que java, linux, javascript, php, css, etc. Il a apporté de nombreuses contributions dans le domaine de l'open source. station de documentation pour les développeurs pour partager certains problèmes de développement technologique pour référence future.
