Todos os produtos
Search

Este produto

    ApsaraVideo Live:Especificações do protocolo de sinalização para acesso WebRTC padrão ao GRTN

    Central de documentação

    ApsaraVideo Live:Especificações do protocolo de sinalização para acesso WebRTC padrão ao GRTN

    Última atualização: Aug 19, 2026

    O RTS (RTS) baseia-se nas interações de sinalização do Web Real-Time Communication (WebRTC). O RTS aproveita a cobertura global e os algoritmos avançados de agendamento dos nós de transmissão ao vivo da Alibaba Cloud. Este tópico descreve o protocolo de sinalização para acesso WebRTC padrão ao GRTN e destina-se a desenvolvedores com conhecimento básico em WebRTC.

    Informações de contexto

    O ApsaraVideo Live oferece o recurso adicional RTS (RTS) para resolver problemas de latência, que podem chegar a 3-6 segundos ou mais com o uso de TCP. O RTS utiliza o protocolo UDP e proporciona uma experiência de transmissão ao viva de alta definição, com latência em milissegundos, alta concorrência e fácil integração. Esse recurso foi projetado para construir um ecossistema aberto e padronizado. Além do SDK RTS dedicado da Alibaba Cloud, o RTS suporta clientes personalizados que utilizam sinalização compatível com WebRTC para ingerir e puxar fluxos de áudio e vídeo dos nós de transmissão ao vivo. Isso permite que os clientes utilizem o service RTS da Alibaba Cloud em grande escala, de forma conveniente e autogerenciada.

    O GRTN agora oferece resiliência para condições de rede adversas.

    Pré-requisitos

    Fluxo de interação de sinalização

    A figura a seguir ilustra o fluxo de interação de sinalização:

    001

    Fluxo de interação de sinalização

    1. O cliente envia uma requisição offer.

      1. Crie uma RTCPeerConnection local, defina a propriedade Stream Direction para recebimento de áudio e vídeo e gere um SDP offer.

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

      2. Envie uma requisição de pull de stream no formato JSON para o service ApsaraVideo Live por meio de uma requisição HTTPS POST. Para mais detalhes sobre o formato do protocolo, consulte Signaling protocol definition.

        • O campo version especifica a versão do protocolo. A versão atual é fixa em 2.

        • O campo sdk_version indica a versão do SDK. Você pode personalizar esse campo.

      3. Após gerar o conteúdo do protocolo, envie-o ao endpoint de sinalização do service ApsaraVideo Live em uma requisição POST para concluir a interação de sinalização. O corpo JSON da requisição contém a URL do stream a ser puxado.

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

        O endpoint de sinalização é quase idêntico à URL do stream, diferindo apenas pelo prefixo do protocolo:

        • Endpoint de sinalização: https://domain/app/streamname?auth=xxx.

        • URL do stream: artc://domain/app/streamname?auth=xxx.

    2. O servidor responde com um SDP answer.

      O servidor do ApsaraVideo Live verifica a segurança da requisição, gera um SDP answer e retorna as informações do nó ao cliente no corpo da resposta. Para mais detalhes sobre o formato do protocolo, consulte Signaling protocol definition.

    3. O cliente estabelece uma conexão ICE.

      1. Ao receber o SDP answer, defina-o na RTCPeerConnection.

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

      2. A RTCPeerConnection inicia o processo de estabelecimento da conexão ICE e o subsequente processo DTLS. Após o estabelecimento do canal de mídia, o cliente recebe o fluxo de mídia do service ApsaraVideo Live. Isso conclui o acesso WebRTC padrão para pull e reprodução de streams.

    4. Desconexão.

      Para desconectar e interromper a ingestão ou reprodução do stream, envie uma mensagem DTLS Alert.

      断开连接

    Exemplo de demonstração 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);
}

    Definição do protocolo de sinalização

    O protocolo de sinalização RTS utiliza HTTPS (conexões de curta duração) e o formato JSON. Veja um exemplo abaixo:

    {
    "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 ..."
    }
}

    Reprodução

    • Descrição do protocolo de reprodução

      Tabela 1. Parâmetros da requisição

      Parâmetro

      Tipo

      Obrigatório

      Descrição

      mode

      string

      Sim

      Modo de operação. Defina o valor como live.

      version

      int

      Sim

      Número da versão do protocolo. Defina o valor como 2.

      push_stream

      string

      Não

      URL de ingestão de stream.

      pull_streams

      []object

      Não

      Objeto de pull de stream. É possível puxar múltiplos streams. Para mais informações, consulte a tabela a seguir.

      sdk_version

      string

      Não

      Número da versão do SDK.

      jsep.type

      string

      Sim

      Tipo de SDP. Defina o valor como offer.

      jsep.sdp

      string

      Sim

      Descrição do SDP.
      Tabela 2. Parâmetros de pull_stream

      Campo

      Tipo

      Obrigatório

      Descrição

      url

      string

      Sim

      URL para pull de stream. Exemplo: artc://<pull_stream_url>.

      amsid

      []string

      Sim

      msid de áudio para pull de stream. Em cenários de transmissão ao vivo, defina o valor como rts audio.

      vmsid

      []string

      Sim

      msid de vídeo para pull de stream. Em cenários de transmissão ao vivo, defina o valor como rts video.
      Tabela 3. Parâmetros da resposta

      Campo

      Tipo

      Obrigatório

      Descrição

      code

      int

      Sim

      Código de retorno. O valor 200 indica sucesso. Para mais informações sobre códigos de erro, consulte a tabela de descrição de códigos de erro abaixo.

      trace_id

      string

      Sim

      ID de requisição globalmente único gerado pela CDN. Salve este ID para auxiliar na localização e solução de problemas de requisições.

      jsep.type

      string

      Sim

      Tipo de SDP. Defina o valor como answer.

      jsep.sdp

      string

      Sim

      SDP gerado pela Alibaba Cloud CDN para busca na origem.

    • Exemplo de requisição de reprodução

      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: Para evitar artefatos de vídeo durante a reprodução em redes instáveis, modifique o SDP.

      Após gerar um offer para um stream de assinatura H5 (recvonly) e antes de chamar setLocalDescription, modifique o SDP. Localize a linha nas propriedades de vídeo H.264 semelhante ao seguinte:

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

      Adicione sps-pps-idr-in-keyframe=1 à linha:

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

      O GRTN responde a essa alteração e ativa o recurso no navegador.

    • Tratamento de erros

      Se a requisição de sinalização for válida, o servidor retorna uma resposta 200. Para obter o resultado específico, analise a propriedade code no corpo da resposta JSON. A propriedade code segue o padrão de códigos de resposta HTTP. Veja um exemplo:

      Response:
{
   "code": 200, // 200: Success. For non-200 codes, see the definitions below.
   "message": "success"  // Description for non-200 error codes.
}
      Tabela 4. Parâmetros da resposta

      Parâmetro

      Tipo

      Descrição

      code

      int

      Código de resposta. Para mais informações sobre formato e definições, consulte a tabela a seguir.

      message

      string

      Descrição do erro.
      Tabela 5. Descrição dos códigos de erro

      Código de erro

      Descrição

      403

      Falha na autenticação.

      404

      O stream não existe.

      611

      O cliente deve retornar ao TCP para reprodução.

      302

      O cliente deve enviar uma nova requisição de sinalização para um novo endpoint de service.

    Ingestão de stream

    • Descrição do protocolo de ingestão de stream

      Tabela 6. Parâmetros da requisição

      Parâmetro

      Tipo

      Obrigatório

      Descrição

      mode

      string

      Sim

      Modo de operação. Defina o valor como live.

      version

      int

      Sim

      Número da versão do protocolo. Defina o valor como 2.

      push_stream

      string

      Não

      URL de ingestão de stream.

      sdk_version

      string

      Não

      Número da versão do SDK.

      jsep.type

      string

      Sim

      Tipo de SDP. Defina o valor como offer.

      jsep.sdp

      string

      Sim

      Descrição do SDP.
      Tabela 7. Parâmetros da resposta

      Campo

      Tipo

      Obrigatório

      Descrição

      code

      int

      Sim

      Código de retorno. O valor 200 indica sucesso. Para mais informações sobre códigos de erro, consulte a tabela de descrição de códigos de erro abaixo.

      trace_id

      string

      Sim

      ID de requisição globalmente único gerado pela CDN. Salve este ID para auxiliar na localização e solução de problemas de requisições.

      jsep.type

      string

      Sim

      Tipo de SDP. Defina o valor como answer.

      jsep.sdp

      string

      Sim

      SDP gerado pela Alibaba Cloud CDN para busca na origem.

    • Exemplo de requisição de ingestão de stream

      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 ..."
    }
}

      Na mensagem de sinalização, push_stream especifica a URL de ingestão do stream, de forma semelhante à ingestão via RTMP. Observe:

      • Especifique o msid no SDP. O GRTN utiliza o msid como identificador exclusivo da mídia.

      • Não há suporte para negociação de mídia na ingestão de streams. Para um único msid de mídia especificado pelo cliente, apenas um tipo de codificação é permitido. O GRTN não realiza seleção. Atualmente, o GRTN suporta AAC, Opus, H.264 e H.265.

      • áudio

        audio1

        audio2

      • vídeo

        video1

        video2

    • Tratamento de erros

      Se a requisição de sinalização for válida, o servidor retorna uma resposta 200. Para obter o resultado específico, analise a propriedade code no corpo da resposta JSON. A propriedade code segue o padrão de códigos de resposta HTTP. Veja um exemplo:

      Response:
{
   "code": 200, // 200: Success. For non-200 codes, see the definitions below.
   "message": "success"  // Description for non-200 error codes.
}
      Tabela 8. Parâmetros da resposta

      Parâmetro

      Tipo

      Descrição

      code

      int

      Código de resposta. Para mais informações sobre formato e definições, consulte a tabela a seguir.

      message

      string

      Descrição do erro.
      Tabela 9. Descrição dos códigos de erro

      Código de erro

      Descrição

      403

      Falha na autenticação.

      611

      O cliente deve retornar ao TCP.

      302

      O cliente deve enviar uma nova requisição de sinalização para um novo endpoint de service.

    SDP Aprimorado

    Durante a sinalização, o SDP descreve as informações de mídia. A negociação comum de SDP baseia-se na RFC 4566. O RTS da Alibaba Cloud estende esse padrão com semânticas mais ricas, compatíveis com a indústria de transmissão ao vivo. O RTS suporta mais formatos de encapsulamento de áudio e vídeo, além de protocolos de comunicação diversos. Isso supera limitações do WebRTC, como o suporte exclusivo a áudio Opus e a ausência de suporte a B-frames em vídeo, atendendo às necessidades em evolução da indústria de streaming de mídia.

    Suporte a áudio AAC na ingestão e pull de streams

    O RTS suporta o transporte de qualquer formato de áudio AAC transportável via RTMP, incluindo AAC-LC, HE-AACv1 e HE-AACv2.

    O RTS aceita o transporte de áudio AAC no formato LATM. O LATM transmite informações de codificação de áudio in-band (enviadas com cada pacote de áudio) ou out-of-band (enviadas apenas uma vez), dependendo se o próprio fluxo de áudio contém essas informações. Isso é determinado por muxconfigPresent no Audio Mux Element, tornando o LATM mais flexível que o ADTS. Se o AudioSpecificConfig não mudar, as informações do StreamMuxConfig (AudioSpecificConfig) podem ser transmitidas inicialmente na sessão SDP.

    • Suporte à ingestão de áudio AAC

      O SDP offer pode incluir informações AAC para informar ao servidor o formato de áudio ingerido. Também é possível adicionar config=StreamMuxConfig à linha FMTP. Essa configuração é montada a partir das informações AudioSpecificConfig do stream ingerido e transmite esses dados ao servidor para gerar o cabeçalho AAC.

      SDP offer:

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

    • Suporte ao pull de áudio AAC

      Durante a interação de sinalização, o RTS analisa as informações de codificação de áudio da fonte de ingestão e retorna os dados correspondentes na resposta de negociação. A tabela a seguir fornece detalhes.

      SDP offerSDP answer
      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

      Neste caso, adicionar SBR-enabled=1 à linha fmtp do áudio MP4A-LATM no SDP answer indica HE-AAC. Adicionar tanto SBR-enabled=1 quanto PS-enabled=1 indica HE-AACv2. Os identificadores SBR e PS são adicionados progressivamente para representar os diferentes formatos AAC, refletindo a evolução tecnológica do AAC-LC ao HE-AACv2. Além disso, config=StreamMuxConfig é adicionado à linha fmtp. Isso é montado a partir das informações AudioSpecificConfig do stream ingerido e fornece detalhes sobre os parâmetros de codificação de áudio. O cliente pode utilizar essas informações conforme necessário.

      002

    Suporte a vídeo H.265 na ingestão e pull de streams

    • Suporte à ingestão de vídeo H.265

      O SDP offer pode incluir informações H.265 para informar ao servidor o formato de vídeo ingerido.

      SDP Offer:

      a=rtpmap:102 H265/90000

    • Suporte ao pull de vídeo H.265

      Durante a interação de sinalização para pull de stream, o servidor obtém as informações de codificação de vídeo (como H.264 ou H.265) do stream de origem e negocia com base nesses dados.

      SDP offerSDP answer
      a=rtpmap:102 H265/90000
      a=rtpmap:122 H265/90000
    a=fmtp:122

    Suporte a vídeo com B-frames na ingestão e pull de streams

    • Suporte à ingestão de B-frames

      O stream de origem para ingestão pode conter B-frames.

    • Suporte ao pull de B-frames

      Durante a interação de sinalização, o cliente pode adicionar um campo ao SDP offer para indicar se suporta a análise de vídeo com B-frames. Por exemplo, adicione BFrame-enabled = 1 à linha fmtp de vídeo para indicar suporte a B-frames. Nesse caso, RTP timestamp = PTS e o número de sequência é incrementado. O cliente realiza a decodificação normal com base no número de sequência. Se não houver suporte a B-frames, o RTS transcodifica o stream de vídeo de origem para remover os B-frames.

      Quando há B-frames, RTP timestamp = PTS e o número de sequência é incrementado. O cliente realiza a decodificação normal com base no número de sequência.

      O servidor também suporta o retorno de um cabeçalho de extensão commit timestamp (CTS) adicional para clientes que exigem cálculo preciso do DTS (PTS = DTS + CTS). Se o SDP offer contiver a=extmap:{$id} uri:webrtc:rtc:rtp-hdrext:video:CompositionTime, o RTS adiciona um CTS extension header com extension identifier = {$id} ao primeiro pacote RTP de cada quadro de vídeo. O id é determinado pelo SDP offer.

      O RTS oferece aos clientes flexibilidade para decidir se aceitam vídeo com B-frames e se precisam de informações CTS adicionais. Construir capacidades de comunicação mais universais é um princípio central do RTS.

    As figuras a seguir mostram um trecho do SDP offer e um exemplo de pacotes capturados no pull de stream:

    Offer SDP片段

    004

    Suporte para transporte de metadados na sinalização de ingestão de stream

    A ingestão de stream via RTMP utiliza metadados RTMP para transportar informações, que podem ser fornecidas a callbacks de ingestão e clientes de pull de stream. Como o transporte WebRTC não suporta metadados nativamente, o RTS permite o transporte de informações adicionais na mensagem de sinalização para gerar metadados no stream ingerido.

    Adicione um campo metadata ao corpo da mensagem de sinalização de ingestão de stream:

    {
    "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"
    }
}

    Conceitos de MSID

    Para mais informações sobre MSID, consulte

    The Msid Mechanism

    . Observe o seguinte:

    Msid