Tous les produits
Search

Ce produit

    ApsaraVideo Live:Spécifications du protocole de signalisation pour l'accès WebRTC standard à GRTN

    Centre de documentation

    ApsaraVideo Live:Spécifications du protocole de signalisation pour l'accès WebRTC standard à GRTN

    Dernière mise à jour :Aug 19, 2026

    RTS (RTS) s'appuie sur les interactions de signalisation Web Real-Time Communication (WebRTC). RTS tire parti de la couverture mondiale et des algorithmes d'ordonnancement avancés des nœuds de diffusion en direct d'Alibaba Cloud. Cette rubrique décrit le protocole de signalisation pour l'accès WebRTC standard à GRTN et s'adresse aux développeurs disposant d'une compréhension de base de WebRTC.

    Informations générales

    ApsaraVideo Live propose la fonctionnalité à valeur ajoutée RTS (RTS) pour résoudre les problèmes de latence, qui peuvent atteindre 3 à 6 secondes ou plus lors de l'utilisation de TCP. RTS utilise le protocole UDP et offre une expérience de diffusion en direct à faible latence (de l'ordre de la milliseconde), à haute concurrence et en haute définition, facile à intégrer. RTS est conçu pour bâtir un écosystème ouvert et standard. Outre le SDK RTS dédié d'Alibaba Cloud, RTS prend en charge les clients personnalisés qui utilisent une signalisation similaire à WebRTC pour ingérer et extraire des flux audio et vidéo depuis les nœuds de diffusion en direct. Cela permet aux clients d'utiliser le service Alibaba Cloud RTS à grande échelle, de manière pratique et autonome.

    GRTN offre désormais une résilience face aux mauvaises conditions réseau.

    Prérequis

    Flux d'interaction de signalisation

    La figure suivante illustre le flux d'interaction de signalisation :

    001

    Flux d'interaction de signalisation

    1. Le client envoie une requête d'offre.

      1. Le client crée une RTCPeerConnection locale, définit la propriété Stream Direction pour la réception audio et vidéo, et crée une offre SDP.

        // Enable audio and video, recvonly or sendonly
{ offerToReceiveVideo: true, offerToReceiveAudio: true }

      2. Le client envoie une requête d'extraction de flux au format JSON au service ApsaraVideo Live via une requête HTTPS POST. Pour plus d'informations sur le format du protocole, consultez Définition du protocole de signalisation.

        • Le champ version spécifie la version du protocole. La version actuelle est fixée à 2.

        • Le champ sdk_version spécifie la version du SDK. Vous pouvez personnaliser ce champ.

      3. Une fois le contenu du protocole généré, le client l'envoie au point de terminaison de signalisation du service ApsaraVideo Live dans une requête POST pour finaliser l'interaction de signalisation. Le corps JSON de la requête contient l'URL du flux à extraire.

        POST /app/streamname?auth=xxx HTTP/1.1
Host: domain
Connection: keep-alive
Content-Length: 2205
Content-Type: application/json
        Remarque

        Le point de terminaison de signalisation est presque identique à l'URL du flux, mais le préfixe de protocole diffère :

        • Point de terminaison de signalisation : https://domain/app/streamname?auth=xxx.

        • URL du flux : artc://domain/app/streamname?auth=xxx.

    2. Le serveur répond avec une réponse SDP.

      Le serveur ApsaraVideo Live vérifie la sécurité de la requête, génère une réponse SDP et renvoie les informations du nœud au client dans le corps de la réponse. Pour plus d'informations sur le format du protocole, consultez Définition du protocole de signalisation.

    3. Le client établit une connexion ICE.

      1. Après avoir reçu la réponse SDP, le client définit la réponse sur la RTCPeerConnection.

        peerConnection.setRemoteDescription(new RTCSessionDescription(answer.jsep));

      2. La RTCPeerConnection démarre le processus d'établissement de la connexion ICE et le processus DTLS suivant. Une fois le canal multimédia établi, le client peut recevoir le flux multimédia du service ApsaraVideo Live. Cela complète l'accès WebRTC standard pour l'extraction et la lecture de flux.

    4. Déconnexion.

      Pour se déconnecter et arrêter l'ingestion ou la lecture du flux, le client envoie un message DTLS Alert.

      断开连接

    Exemple de démonstration H5

    // Create peer connection and local offer sdp.
peerConnection = new RTCPeerConnection();
peerConnection.onicecandidate = iceCandidateCallback;
peerConnection.ontrack = remoteStreamCallback;
peerConnection.createOffer({ offerToReceiveVideo: true, offerToReceiveAudio: true })
      .then(signaling_pull).catch(errorHandler);

// Send a stream pulling request to ApsaraVideo Live.
function signaling_pull(offer_sdp) {
  console.log('local offer sdp', offer_sdp);

  peerConnection.setLocalDescription(offer_sdp).then(function() {
    // Get the stream pulling URL.
    var stream_url = $("#stream_url").val();
    console.log("stream url:" , stream_url);

    // Add sdk and protocol versions.
    var protocol_version = 2;
    var sdk_version = "0.0.1";

    $.ajax({url: stream_url, data: JSON.stringify({
          mode: "live",
          version: protocol_version,
          sdk_version: sdk_version,
          jsep:description,
      }),
      type: "post",
      success:function(result){
          var signal = JSON.parse(result);
          peerConnection.setRemoteDescription(new RTCSessionDescription(signal.jsep)).then(function() {
              console.log("get remote answer sdp: ", signal.jsep.sdp);
          }).catch(errorHandler);
      }});
  }).catch(errorHandler);
}

    Définition du protocole de signalisation

    Le protocole de signalisation RTS utilise HTTPS (connexions éphémères) et le format JSON. Voici un exemple :

    {
    "version":2,
    "sdk_version":"0.0.1",
    "mode":"live",
    "pull_streams":[
        {
            "url":"artc://your.domain.com/live/testname",
            "amsid":[
                "rts audio"
            ],
            "vmsid":[
                "rts video"
            ]
        }
    ],
    "jsep":{
        "type":"offer",
        "sdp":"v=0\n\ro=- 6839248142876176651 2 IN IP4 127.0.0.1\n\rs=-\n\r... Omitted ..."
    }
}

    Lecture

    • Description du protocole de lecture

      Tableau 1. Paramètres de requête
      Paramètre Type Obligatoire Description
      mode string Oui Le mode. Définissez la valeur sur live.
      version int Oui Le numéro de version du protocole. Définissez la valeur sur 2.
      push_stream string Non L'URL d'ingestion du flux.
      pull_streams []object Non L'objet d'extraction de flux. Plusieurs flux peuvent être extraits. Pour plus d'informations, consultez le tableau ci-dessous.
      sdk_version string Non Le numéro de version du SDK.
      jsep.type string Oui Le type SDP. Définissez la valeur sur offer.
      jsep.sdp string Oui La description SDP.
      Tableau 2. Paramètres pull_stream
      Champ Type Obligatoire Description
      url string Oui L'URL d'extraction du flux. Exemple : artc://<pull_stream_url>.
      amsid []string Oui Le msid audio pour l'extraction du flux. Dans les scénarios de diffusion en direct, définissez la valeur sur rts audio.
      vmsid []string Oui Le msid vidéo pour l'extraction du flux. Dans les scénarios de diffusion en direct, définissez la valeur sur rts video.
      Tableau 3. Paramètres de réponse
      Champ Type Obligatoire Description
      code int Oui Le code de retour. Une valeur de 200 indique un succès. Pour plus d'informations sur les codes d'erreur, consultez le tableau de description des codes d'erreur ci-dessous.
      trace_id string Oui Un ID de requête unique généré globalement par CDN. Enregistrez cet ID pour aider à localiser et à dépanner les requêtes.
      jsep.type string Oui Le type SDP. Définissez la valeur sur answer.
      jsep.sdp string Oui Le SDP généré par Alibaba Cloud CDN pour la récupération à l'origine.

    • Exemple de requête de lecture

      Request:
{
    "version":2,
    "sdk_version":"0.0.1",
    "mode":"live",
    "pull_streams":[
        {
            "url":"artc://your.domain.com/live/testname",
            "amsid":[
                "rts audio"
            ],
            "vmsid":[
                "rts video"
            ]
        }
    ],
    "jsep":{
        "type":"offer",
        "sdp":"v=0\n\ro=- 6839248142876176651 2 IN IP4 127.0.0.1\n\rs=-\n\r... Omitted ..."
    }
}

Response:
{
    "trace_id":"2_1591173296_101.227.0.169_702080732320_dec327eb6eed0e0b07b349c8a5653eca",
    "code":200,
    "jsep":{
        "type":"answer",
        "sdp":"v=0\r\no=- 1591173291 2 IN IP4 127.0.0.1\n\r ... Omitted ..."
    }
}

      sps-pps-idr-in-keyframe : Pour éviter les artefacts vidéo lors de la lecture sur des réseaux médiocres, modifiez le SDP.

      Après la génération d'une offre pour un flux d'abonnement H5 (recvonly) et avant d'appeler setLocalDescription, modifiez le SDP. Recherchez la ligne dans les propriétés vidéo H.264 similaire à la suivante :

      a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f

      Ajoutez sps-pps-idr-in-keyframe=1 à la ligne :

      a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f;sps-pps-idr-in-keyframe=1

      GRTN répond à cette modification et active la fonctionnalité dans le navigateur.

    • Gestion des erreurs

      Si la requête de signalisation est valide, le serveur renvoie une réponse 200. Pour obtenir le résultat spécifique, analysez la propriété code dans le corps de la réponse JSON. La propriété code suit un modèle de code de réponse HTTP. Voici un exemple :

      Response:
{
   "code": 200, // 200: Success. For non-200 codes, see the definitions below.
   "message": "success"  // Description for non-200 error codes.
}
      Tableau 4. Paramètres de réponse
      Paramètre Type Description
      code int Le code de réponse. Pour plus d'informations sur le format et les définitions, consultez le tableau suivant.
      message string La description de l'erreur.
      Tableau 5. Descriptions des codes d'erreur
      Code d'erreur Description
      403 Échec de l'authentification.
      404 Le flux n'existe pas.
      611 Le client doit revenir à TCP pour la lecture.
      302 Le client doit envoyer une nouvelle requête de signalisation à un nouveau point de terminaison de service.

    Ingestion de flux

    • Description du protocole d'ingestion de flux

      Tableau 6. Paramètres de requête
      Paramètre Type Obligatoire Description
      mode string Oui Le mode. Définissez la valeur sur live.
      version int Oui Le numéro de version du protocole. Définissez la valeur sur 2.
      push_stream string Non L'URL d'ingestion du flux.
      sdk_version string Non Le numéro de version du SDK.
      jsep.type string Oui Le type SDP. Définissez la valeur sur offer.
      jsep.sdp string Oui La description SDP.
      Tableau 7. Paramètres de réponse
      Champ Type Obligatoire Description
      code int Oui Le code de retour. Une valeur de 200 indique un succès. Pour plus d'informations sur les codes d'erreur, consultez le tableau de description des codes d'erreur ci-dessous.
      trace_id string Oui Un ID de requête unique généré globalement par CDN. Enregistrez cet ID pour aider à localiser et à dépanner les requêtes.
      jsep.type string Oui Le type SDP. Définissez la valeur sur answer.
      jsep.sdp string Oui Le SDP généré par Alibaba Cloud CDN pour la récupération à l'origine.

    • Exemple de requête d'ingestion de flux

      Request:
{
    "version":2,
    "sdk_version":"0.0.1",
    "mode":"rtc",
    "push_stream":"artc://host/app/name",
    "jsep":{
        "type":"offer",
        "sdp":"v=0\r\no=- 1385856200224536561 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE 0 1 2\r\na=extmap-allow-mixed\r\na=msid-semantic: WMS rts\r\nm=audio 9 UDP/TLS/RTP/SAVPF 111 63 103 104 9 0 8 106 105 13 110 112 113 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:iQyM\r\na=ice-pwd:D3GXKCcUGvW9djaAozff5ppT\r\na=ice-options:trickle\r\na=fingerprint:sha-256 20:50:72:9B:A2:C0:D8:50:AD:D0:EF:A7:62:8F:EF:C3:AB:86:D5:B6:3E:17:22:69:79:5B:CE:E8:42:33:B5:E4\r\na=setup:actpass\r\na=mid:0\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=sendrecv\r\na=msid:rts audio\r\na=rtcp-mux\r\na=rtpmap:111 opus/48000/2\r\na=rtcp-fb:111 transport-cc\r\na=rtcp-fb:111 nack\r\na=fmtp:111 minptime=10;useinbandfec=1\r\na=rtpmap:63 red/48000/2\r\na=fmtp:63 111/111\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:104 ISAC/32000\r\na=rtpmap:9 G722/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:106 CN/32000\r\na=rtpmap:105 CN/16000\r\na=rtpmap:13 CN/8000\r\na=rtpmap:110 telephone-event/48000\r\na=rtpmap:112 telephone-event/32000\r\na=rtpmap:113 telephone-event/16000\r\na=rtpmap:126 telephone-event/8000\r\na=ssrc:3411287802 cname:s4eR7OuKnnPL0vKS\r\na=ssrc:3411287802 msid:rts audio\r\na=ssrc:3411287802 mslabel:rts\r\na=ssrc:3411287802 label:audio\r\nm=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 127 121 125 107 108 109 124 120 123 119 35 36 41 42 114 115 116 117 118\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:iQyM\r\na=ice-pwd:D3GXKCcUGvW9djaAozff5ppT\r\na=ice-options:trickle\r\na=fingerprint:sha-256 20:50:72:9B:A2:C0:D8:50:AD:D0:EF:A7:62:8F:EF:C3:AB:86:D5:B6:3E:17:22:69:79:5B:CE:E8:42:33:B5:E4\r\na=setup:actpass\r\na=mid:1\r\na=extmap:14 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:13 urn:3gpp:video-orientation\r\na=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay\r\na=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type\r\na=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing\r\na=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id\r\na=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id\r\na=sendrecv\r\na=msid:rts video\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:96 VP8/90000\r\na=rtcp-fb:96 goog-remb\r\na=rtcp-fb:96 transport-cc\r\na=rtcp-fb:96 ccm fir\r\na=rtcp-fb:96 nack\r\na=rtcp-fb:96 nack pli\r\na=rtpmap:97 rtx/90000\r\na=fmtp:97 apt=96\r\na=rtpmap:98 VP9/90000\r\na=rtcp-fb:98 goog-remb\r\na=rtcp-fb:98 transport-cc\r\na=rtcp-fb:98 ccm fir\r\na=rtcp-fb:98 nack\r\na=rtcp-fb:98 nack pli\r\na=fmtp:98 profile-id=0\r\na=rtpmap:99 rtx/90000\r\na=fmtp:99 apt=98\r\na=rtpmap:100 VP9/90000\r\na=rtcp-fb:100 goog-remb\r\na=rtcp-fb:100 transport-cc\r\na=rtcp-fb:100 ccm fir\r\na=rtcp-fb:100 nack\r\na=rtcp-fb:100 nack pli\r\na=fmtp:100 profile-id=2\r\na=rtpmap:101 rtx/90000\r\na=fmtp:101 apt=100\r\na=rtpmap:127 H264/90000\r\na=rtcp-fb:127 goog-remb\r\na=rtcp-fb:127 transport-cc\r\na=rtcp-fb:127 ccm fir\r\na=rtcp-fb:127 nack\r\na=rtcp-fb:127 nack pli\r\na=fmtp:127 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f\r\na=rtpmap:121 rtx/90000\r\na=fmtp:121 apt=127\r\na=rtpmap:125 H264/90000\r\na=rtcp-fb:125 goog-remb\r\na=rtcp-fb:125 transport-cc\r\na=rtcp-fb:125 ccm fir\r\na=rtcp-fb:125 nack\r\na=rtcp-fb:125 nack pli\r\na=fmtp:125 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f\r\na=rtpmap:107 rtx/90000\r\na=fmtp:107 apt=125\r\na=rtpmap:108 H264/90000\r\na=rtcp-fb:108 goog-remb\r\na=rtcp-fb:108 transport-cc\r\na=rtcp-fb:108 ccm fir\r\na=rtcp-fb:108 nack\r\na=rtcp-fb:108 nack pli\r\na=fmtp:108 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f\r\na=rtpmap:109 rtx/90000\r\na=fmtp:109 apt=108\r\na=rtpmap:124 H264/90000\r\na=rtcp-fb:124 goog-remb\r\na=rtcp-fb:124 transport-cc\r\na=rtcp-fb:124 ccm fir\r\na=rtcp-fb:124 nack\r\na=rtcp-fb:124 nack pli\r\na=fmtp:124 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f\r\na=rtpmap:120 rtx/90000\r\na=fmtp:120 apt=124\r\na=rtpmap:123 H264/90000\r\na=rtcp-fb:123 goog-remb\r\na=rtcp-fb:123 transport-cc\r\na=rtcp-fb:123 ccm fir\r\na=rtcp-fb:123 nack\r\na=rtcp-fb:123 nack pli\r\na=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d001f\r\na=rtpmap:119 rtx/90000\r\na=fmtp:119 apt=123\r\na=rtpmap:35 H264/90000\r\na=rtcp-fb:35 goog-remb\r\na=rtcp-fb:35 transport-cc\r\na=rtcp-fb:35 ccm fir\r\na=rtcp-fb:35 nack\r\na=rtcp-fb:35 nack pli\r\na=fmtp:35 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=4d001f\r\na=rtpmap:36 rtx/90000\r\na=fmtp:36 apt=35\r\na=rtpmap:41 AV1/90000\r\na=rtcp-fb:41 goog-remb\r\na=rtcp-fb:41 transport-cc\r\na=rtcp-fb:41 ccm fir\r\na=rtcp-fb:41 nack\r\na=rtcp-fb:41 nack pli\r\na=rtpmap:42 rtx/90000\r\na=fmtp:42 apt=41\r\na=rtpmap:114 H264/90000\r\na=rtcp-fb:114 goog-remb\r\na=rtcp-fb:114 transport-cc\r\na=rtcp-fb:114 ccm fir\r\na=rtcp-fb:114 nack\r\na=rtcp-fb:114 nack pli\r\na=fmtp:114 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=64001f\r\na=rtpmap:115 rtx/90000\r\na=fmtp:115 apt=114\r\na=rtpmap:116 red/90000\r\na=rtpmap:117 rtx/90000\r\na=fmtp:117 apt=116\r\na=rtpmap:118 ulpfec/90000\r\na=ssrc-group:FID 4075787827 945566690\r\na=ssrc:4075787827 cname:s4eR7OuKnnPL0vKS\r\na=ssrc:4075787827 msid:rts video\r\na=ssrc:4075787827 mslabel:rts\r\na=ssrc:4075787827 label:video\r\na=ssrc:945566690 cname:s4eR7OuKnnPL0vKS\r\na=ssrc:945566690 msid:rts video\r\na=ssrc:945566690 mslabel:rts\r\na=ssrc:945566690 label:video\r\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 0.0.0.0\r\na=ice-ufrag:iQyM\r\na=ice-pwd:D3GXKCcUGvW9djaAozff5ppT\r\na=ice-options:trickle\r\na=fingerprint:sha-256 20:50:72:9B:A2:C0:D8:50:AD:D0:EF:A7:62:8F:EF:C3:AB:86:D5:B6:3E:17:22:69:79:5B:CE:E8:42:33:B5:E4\r\na=setup:actpass\r\na=mid:2\r\na=sctp-port:5000\r\na=max-message-size:262144\r\n"
    }
}

Response:
{
    "trace_id":"...",
    "code":200,
    "jsep":{
        "type":"answer",
        "sdp":"v=0\r\no=- 1657264764 2 IN IP4 127.0.0.1 ... Omitted ..."
    }
}

      Dans le message de signalisation, push_stream spécifie l'URL d'ingestion du flux. Ceci est similaire à l'ingestion de flux RTMP. Remarque :

      • Vous devez spécifier le msid dans le SDP. GRTN utilise le msid comme identifiant unique pour le média.

      • La négociation multimédia n'est pas prise en charge pour l'ingestion de flux. Pour un seul msid multimédia spécifié par le client, un seul type d'encodage est autorisé. GRTN n'effectue aucune sélection. GRTN prend actuellement en charge AAC, Opus, H.264 et H.265.

      • audio

        audio1

        audio2

      • vidéo

        video1

        video2

    • Gestion des erreurs

      Si la requête de signalisation est valide, le serveur renvoie une réponse 200. Pour obtenir le résultat spécifique, analysez la propriété code dans le corps de la réponse JSON. La propriété code suit un modèle de code de réponse HTTP. Voici un exemple :

      Response:
{
   "code": 200, // 200: Success. For non-200 codes, see the definitions below.
   "message": "success"  // Description for non-200 error codes.
}
      Tableau 8. Paramètres de réponse
      Paramètre Type Description
      code int Le code de réponse. Pour plus d'informations sur le format et les définitions, consultez le tableau suivant.
      message string La description de l'erreur.
      Tableau 9. Descriptions des codes d'erreur
      Code d'erreur Description
      403 Échec de l'authentification.
      611 Le client doit revenir à TCP.
      302 Le client doit envoyer une nouvelle requête de signalisation à un nouveau point de terminaison de service.

    SDP amélioré

    Lors de la signalisation, le SDP est utilisé pour décrire les informations multimédias. La négociation SDP courante est basée sur la RFC 4566. Alibaba Cloud RTS étend cela avec une sémantique plus riche compatible avec l'industrie de la diffusion en direct. RTS prend en charge davantage de formats d'encapsulation audio et vidéo et de protocoles de communication. Cela permet de surmonter les limitations de WebRTC, telles que la prise en charge exclusive de l'audio Opus et l'absence de prise en charge des images B dans la vidéo, afin de répondre aux besoins évolutifs de l'industrie des médias en continu.

    Prise en charge de l'audio AAC dans l'ingestion et l'extraction de flux

    RTS prend en charge le transport de tout format audio AAC pouvant être transporté dans RTMP, y compris AAC-LC, HE-AACv1 et HE-AACv2.

    RTS prend en charge le transport audio AAC au format LATM. LATM peut transmettre les informations d'encodage audio soit en bande (envoyées avec chaque paquet audio), soit hors bande (envoyées une seule fois), selon que le flux audio lui-même contient ces informations. Cela est déterminé par muxconfigPresent dans l'élément Audio Mux. Cela rend LATM plus flexible qu'ADTS. Si l'AudioSpecificConfig ne change pas, les informations StreamMuxConfig (AudioSpecificConfig) peuvent être transmises initialement dans la session SDP.

    • Prise en charge de l'ingestion de flux pour l'audio AAC

      Le SDP d'offre peut inclure des informations AAC pour informer le serveur du format audio ingéré. Vous pouvez également ajouter config=StreamMuxConfig à la ligne FMTP. Cette configuration est assemblée à partir des informations AudioSpecificConfig du flux ingéré et transmet ces informations au serveur pour générer l'en-tête AAC.

      SDP d'offre :

      a=rtpmap:125 MP4A-LATM/48000/2
a=fmtp:125 config=4000232000;cpresent=0;object=2;profile-level-id=1

    • Prise en charge de l'extraction de flux pour l'audio AAC

      Lors de l'interaction de signalisation, RTS analyse les informations d'encodage audio depuis la source d'ingestion et renvoie les informations correspondantes dans la réponse de négociation. Le tableau suivant fournit les détails.

      SDP d'offreSDP de réponse
      AAC-LCHE-AACv1HE-AACv2
      m=audio 9 UDP/RTP/AVPF 120 96 
a=rtpmap:120 MP4A-LATM/44100/2  
      AudioSpecificConfig = 0x1210
      AudioSpecificConfig = 2b920800
      AudioSpecificConfig = eb8a0800
      a=rtpmap:120 MP4A-LATM/44100/2
a=fmtp:120 cpresent=0;profile-level-id=1;object=2;config=400024203fc0
      a=rtpmap:120 MP4A-LATM/44100/2 
    a=fmtp:120 cpresent=0;profile-level-id=1;object=2;config=4000572410003fc0;SBR-enabled=1
      a=rtpmap:120 MP4A-LATM/44100/2 
    a=fmtp:120 cpresent=0;object=2;profile-level-id=1;config=4001d71410003fc0;PS-enabled=1;SBR-enabled=1

      Ici, l'ajout de SBR-enabled=1 à la ligne fmtp de l'audio MP4A-LATM dans le SDP de réponse indique HE-AAC. L'ajout simultané de SBR-enabled=1 et de PS-enabled=1 indique HE-AACv2. Les identifiants SBR et PS sont ajoutés progressivement pour représenter les différents formats AAC, reflétant la progression technologique de l'AAC-LC à l'HE-AACv2. De plus, config=StreamMuxConfig est ajouté à la ligne fmtp. Cela est assemblé à partir des informations AudioSpecificConfig du flux ingéré et fournit des informations détaillées sur les paramètres d'encodage audio. Le client peut utiliser ces informations selon ses besoins.

      002

    Prise en charge de la vidéo H.265 dans l'ingestion et l'extraction de flux

    • Prise en charge de l'ingestion de flux pour la vidéo H.265

      Le SDP d'offre peut inclure des informations H.265 pour informer le serveur du format vidéo ingéré.

      SDP d'offre :

      a=rtpmap:102 H265/90000

    • Prise en charge de l'extraction de flux pour la vidéo H.265

      Lors de l'interaction de signalisation pour l'extraction de flux, le serveur obtient les informations d'encodage vidéo (telles que H.264 ou H.265) du flux source et négocie sur la base de ces informations.

      SDP d'offreSDP de réponse
      a=rtpmap:102 H265/90000
      a=rtpmap:122 H265/90000
    a=fmtp:122

    Prise en charge de la vidéo avec images B dans l'ingestion et l'extraction de flux

    • Prise en charge de l'ingestion de flux pour les images B

      Le flux source pour l'ingestion peut contenir des images B.

    • Prise en charge de l'extraction de flux pour les images B

      Lors de l'interaction de signalisation, le client peut ajouter un champ au SDP d'offre pour indiquer s'il prend en charge l'analyse de la vidéo avec des images B. Par exemple, ajoutez BFrame-enabled = 1 à la ligne fmtp vidéo pour indiquer la prise en charge des images B. Dans ce cas, RTP timestamp = PTS et le numéro de séquence s'incrémente. Le client peut effectuer un décodage normal basé sur le numéro de séquence. Si les images B ne sont pas prises en charge, RTS peut transcoder le flux vidéo source pour supprimer les images B.

      Lorsque des images B sont présentes, l'horodatage RTP = PTS et le numéro de séquence s'incrémente. Le client peut effectuer un décodage normal basé sur le numéro de séquence.

      Le serveur prend également en charge le renvoi d'un en-tête d'extension d'horodatage de validation (CTS) supplémentaire pour les clients nécessitant un calcul précis du DTS (PTS = DTS + CTS). Si le SDP d'offre contient a=extmap:{$id} uri:webrtc:rtc:rtp-hdrext:video:CompositionTime, RTS ajoute un en-tête d'extension CTS avec identifiant d'extension = {$id} au premier paquet RTP de chaque image vidéo. L'id est déterminé par le SDP d'offre.

      RTS offre aux clients la flexibilité de décider s'ils acceptent la vidéo avec des images B et s'ils ont besoin d'informations CTS supplémentaires. La construction de capacités de communication plus universelles est un principe fondamental de RTS.

    Les figures suivantes montrent un extrait de SDP d'offre et un exemple de paquets capturés lors de l'extraction de flux :

    Offer SDP片段

    004

    Prise en charge du transport de métadonnées dans la signalisation pour l'ingestion de flux

    L'ingestion de flux RTMP utilise les métadonnées RTMP pour transporter des métadonnées, qui peuvent fournir des informations aux rappels d'ingestion et aux clients d'extraction de flux. Étant donné que le transport WebRTC ne prend pas nativement en charge les métadonnées, RTS prend en charge le transport d'informations supplémentaires dans le message de signalisation pour générer des métadonnées dans le flux ingéré.

    Ajoutez un champ metadata au corps du message de signalisation d'ingestion de flux :

    {
    "version":2,
    "sdk_version":"0.0.1",
    "mode":"rtc",
    "push_stream":"artc://host/app/name",
    "jsep":{
        "type":"offer",
        "sdp":"..."
    },
    "metadata":{
        "framerate":"20",
        "platform":"iOS",
        "audiodatarate":"200",
        "videodatarate":"2000"
    }
}

    Concepts MSID

    Pour plus d'informations sur MSID, consultez

    The Msid Mechanism

    . Notez les points suivants :

    Msid