：Spesifikasi Protokol Sinyal RTS

Proses sinyal

Gambar berikut mengilustrasikan proses sinyal.

Proses Sinyal

1. Klien mengirim permintaan dengan penawaran Session Description Protocol (SDP).

   1. Buat objek RTCPeerConnection di klien, tentukan apakah akan menerima atau mengirim sinyal audio dan video, lalu buat penawaran SDP.

      // Tentukan apakah akan menerima atau mengirim sinyal audio dan video.
      { offerToReceiveVideo: true, offerToReceiveAudio: true }

   2. Kirim permintaan tarik aliran dari klien ke ApsaraVideo Live menggunakan metode HTTPS POST. Badan permintaan adalah string JSON. Untuk detail parameter permintaan, lihat bagian Definisi Protokol Sinyal RTS.

      null

      • Parameter version menentukan versi protokol sinyal RTS. Atur nilainya menjadi 2.

      • Parameter sdk_version menentukan versi SDK RTS. Sesuaikan nilai sesuai kebutuhan.

   3. Kirim permintaan yang telah dibuat ke ApsaraVideo Live berdasarkan URL sinyal menggunakan metode POST. Tentukan URL sumber dalam badan permintaan berformat JSON.

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

      null

      Konten URL sinyal pada dasarnya sama dengan URL sumber, kecuali header protokolnya. Contoh:

      • URL Sinyal: https://domain/app/streamname?auth=xxx

      • URL Sumber: artc://domain/app/streamname?auth=xxx

2. Server mengembalikan respons dengan jawaban SDP.

   Setelah server ApsaraVideo Live memverifikasi permintaan, server menghasilkan jawaban SDP dan mengembalikan respons yang berisi informasi tentang node streaming langsung ke klien. Untuk detail parameter respons, lihat bagian Definisi Protokol Sinyal RTS.

3. Klien memulai Interactive Connectivity Establishment (ICE).

   1. Setelah klien menerima respons dengan jawaban SDP, tentukan deskripsi sesi dalam objek RTCPeerConnection.

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

   2. Gunakan objek RTCPeerConnection untuk memulai ICE dan enkripsi Datagram Transport Layer Security (DTLS). Setelah saluran sinyal terbentuk, klien dapat menarik aliran dari ApsaraVideo Live. Dengan cara ini, Anda dapat mengimplementasikan penarikan aliran dan pemutaran berdasarkan standar WebRTC.

4. Klien memulai pemutusan.

   Klien mengirim pesan peringatan DTLS yang memulai pemutusan untuk menghentikan ingest atau pemutaran aliran.

   

Contoh Kode untuk Pemutar HTML5

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


// CDN live post pull stream request.
function signaling_pull(offer_sdp) {
  console.log('local offer sdp', offer_sdp);

  peerConnection.setLocalDescription(offer_sdp).then(function() {
    // Dapatkan url aliran tarik.
    var stream_url = $("#stream_url").val();
    console.log("stream url:" , stream_url);

    // Tambahkan sdk dan versi protokol.
    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);
}

Definisi Protokol Sinyal RTS

Protokol sinyal RTS membentuk koneksi singkat berbasis HTTPS. Protokol ini menggunakan pesan dalam format JSON. Bagian ini menjelaskan permintaan, respons, dan kode kesalahan berdasarkan protokol sinyal RTS.

Contoh Permintaan

Permintaan:
{
    "version":2,
    "sdk_version":"0.0.1",
    "mode":"live",
    "pull_streams":[
        {
            "url":"artc://demo.aliyundoc.com/liveApp****/liveStream****",
            "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 Konten yang dihilangkan"
    }
}

Contoh Respons Sukses

Respons:
{
    "trace_id":"2_1591173296_101.227.XX.XX_702080732320_dec327eb6eed0e0b07b349c8a565****",
    "code":200,
    "jsep":{
        "type":"answer",
        "sdp":"v=0\r\no=- 1591173291 2 IN IP4 127.0.0.1\n\r Konten yang dihilangkan"
    }
}

Negosiasi SDP yang ditingkatkan

Pesan dipertukarkan dalam format SDP selama sinyal. Negosiasi SDP umumnya didasarkan pada RFC 4566. RTS memperluas lebih banyak semantik untuk membuat negosiasi kompatibel dengan karakteristik industri streaming langsung. RTS mendukung lebih banyak format kontainer video dan audio serta lebih banyak protokol komunikasi, sehingga menyelesaikan masalah bahwa WebRTC hanya mendukung format Opus untuk audio dan tidak mendukung B-frame.

Dukungan Audio AAC

RTS dapat mentransmisikan audio dalam berbagai format AAC melalui RTMP, termasuk AAC-LC, HE-AACv1, dan HE-AACv2. Untuk informasi lebih lanjut tentang format AAC, lihat ISO IEC 14496-3.

RTS dapat mentransmisikan audio dalam format AAC menggunakan format kontainer Low-overhead MPEG-4 Audio Transport Multiplex (LATM). LATM menentukan apakah informasi pengkodean audio ditransmisikan dalam mode in-band atau out-of-band berdasarkan apakah audio berisi informasi pengkodean. Transmisi in-band mengirimkan informasi pengkodean untuk setiap frame audio, sedangkan transmisi out-of-band mengirimkan informasi pengkodean hanya sekali. Parameter muxconfigPresent dalam array AudioMuxElement menentukan apakah informasi dalam AudioSpecificConfig ditransmisikan dalam mode in-band atau out-of-band. Oleh karena itu, LATM lebih fleksibel daripada Audio Data Transport Stream (ADTS). Jika informasi dalam AudioSpecificConfig tetap tidak berubah, informasi dalam StreamMuxConfig dapat pertama kali ditransmisikan dalam pesan SDP.

Selama sinyal, RTS mengurai informasi pengkodean selama ingest aliran audio dan mengembalikan informasi yang diuraikan dalam respons negosiasi, seperti yang ditunjukkan dalam kode berikut.

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

Jika SBR-enabled=1 ditambahkan dalam atribut fmtp MP4A-LATM, format AAC adalah AAC-HE. Jika SBR-enabled=1 dan PS-enabled=1 ditambahkan, format AAC adalah HE-AACv2. Format AAC berkembang dari AAC-LC ke HE-AACv2. Oleh karena itu, bidang SBR dan PS dapat digunakan dalam atribut fmtp untuk menunjukkan format AAC. Selain itu, Anda dapat menambahkan config=StreamMuxConfig dalam atribut fmtp. StreamMuxConfig diperoleh dari AudioSpecificConfig dari aliran yang di-ingest dan berisi parameter yang terkait dengan detail informasi pengkodean. Klien dapat memperoleh detail sesuai kebutuhan.

Untuk informasi lebih lanjut, lihat Parameter Encoder AAC-LC / HE-AACv1 / HE-AACv2.

Dukungan Video H.265

RTS mengurai informasi pengkodean video dalam format H.264 atau H.265 selama ingest aliran dan mengembalikan informasi tentang video dalam format H.264 atau H.265 dalam jawaban SDP.

a=rtpmap:102 H265/90000

a=rtpmap:122 H265/90000
a=fmtp:122

Dukungan Video yang Mengandung B-frame

Selama proses sinyal, klien dapat menambahkan bidang dalam penawaran SDP untuk menentukan apakah akan mendekode video yang mengandung B-frame. Sebagai contoh, jika klien menambahkan BFrame-enabled = 1 dalam atribut fmtp, klien dapat mendekode video yang mengandung B-frame. Dalam hal ini, RTP timestamp = PTS dapat ditambahkan, yang berarti bahwa klien mendekode setiap frame berdasarkan urutan nomor yang meningkat. Jika video yang mengandung B-frame tidak didukung, RTS dapat mentranskode aliran sumber untuk menghapus B-frame.

Selain itu, server dapat mengembalikan composition timestamp (CTS). Hal ini memungkinkan klien untuk menghitung decoding timestamp (DTS) berdasarkan rumus berikut: Presentation timestamp (PTS) = DTS + CTS. Jika penawaran SDP berisi a=extmap:{$id} uri:webrtc:rtc:rtp-hdrext:video:CompositionTime, RTS menambahkan extension identifier = {$id} ke paket Real-time Transport Protocol (RTP) pertama dari setiap frame video. Nilai variabel id ditentukan oleh penawaran SDP yang dikirim oleh klien. Gambar berikut menunjukkan sebagian konten dari penawaran SDP dan tangkapan paket selama penarikan aliran:

RTS memungkinkan klien menentukan apakah akan mendekode video yang mengandung B-frame dan apakah akan mengembalikan informasi CTS. Hal ini memastikan kemampuan komunikasi secara umum.

Mekanisme MSID

Untuk informasi lebih lanjut tentang MSID, lihat Mekanisme Msid.