すべてのプロダクト
Search
ドキュメントセンター

ApsaraVideo Live:GRTNへのアクセスに使用するWebRTCシグナリングの仕様

最終更新日:Aug 30, 2024

リアルタイムストリーミング (RTS) は、ウェブリアルタイム通信 (WebRTC) シグナリングに基づいて実装されます。 RTSは、世界中のAlibaba Cloud Content Delivery Network (CDN) ノードと優れたスケジューリングアルゴリズムを活用して、超低レイテンシーのライブストリーミングを実現しています。 このトピックでは、GRTN (Global Realtime Transport Network) へのアクセスに使用されるWebRTCシグナリングの仕様について説明します。 このトピックは、WebRTCの基本的な知識を習得する開発者を対象としています。

背景情報

伝送制御プロトコル (TCP) プロトコル上のライブストリームは、3〜6秒のレイテンシを有する。 遅延を短縮するために、ApsaraVideo Liveは、ユーザーデータグラムプロトコル (UDP) プロトコルを介してライブストリーミングできる付加価値のあるRTS機能を提供しています。 RTSは、アクセスが簡単で、高解像度でスムーズなライブストリーミングサービスを提供します。これは、ミリ秒単位の超低レイテンシで、数千万の同時リクエストを処理できます。 RTSの設計プロセスでは、オープンで標準的なエコシステムの構築が非常に重要です。 ApsaraVideo Liveが提供するRTS SDKとは別に、WebRTCと同様のシグナリング方法を使用して、独自のクライアントを使用してCDNノードにストリームをプッシュしたり、CDNノードからストリームをプルしたりすることもできます。 ApsaraVideo Liveは、世界中のCDNノードと優れたスケジューリングアルゴリズムを提供し、RTSサービスの大規模な管理と使用を容易にします。

GRTNは、劣悪なネットワーク条件下で良好に機能する能力を提供します。

前提条件

  • ApsaraVideo Liveが有効化されています。 詳細については、「クイックスタート」をご参照ください。

  • RTSは有効です。 詳細については、「RTS機能の有効化」をご参照ください。

  • HTTPSアクセス用のSSL証明書がドメイン名に設定されています。 詳細については、「Configure HTTPS secure acceleration」をご参照ください。

シグナリングプロセス

次の図は、シグナリング処理を示しています。

001

シグナリングプロセス

  1. クライアントは、セッション記述プロトコル (SDP) オファーと共に要求を送信する。

    1. クライアントでRTCPeerConnectionオブジェクトを作成し、オーディオおよびビデオ信号を受信するか送信するかを指定してから、SDPオファーを作成します。

      // Specify whether to receive or send audio and video signals.
      { offerToReceiveVideo: true, offerToReceiveAudio: true }
    2. HTTPS POSTメソッドを使用して、クライアントからApsaraVideo Liveにストリームプルリクエストを送信します。 リクエスト本文はJSON文字列です。 リクエストパラメーターの詳細については、このトピックの「RTSシグナリングプロトコルの定義」をご参照ください。

      • versionパラメータは、RTSシグナリングプロトコルのバージョンを指定する。 値を 2 に設定します。

      • sdk_versionパラメーターは、RTS sdkのバージョンを指定します。 必要に応じてパラメーターを設定できます。

    3. POSTメソッドを使用して、シグナリングURLに基づいて構築されたリクエストをApsaraVideo Liveに送信します。 JSON形式のリクエスト本文でソースURLを指定します。

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

      シグナリングURLの内容は、プロトコルヘッダを除いて、ソースURLの内容と基本的に同じである。 次のURLに例を示します。

      • シグナリングURL: https://domain/app/streamname?auth=xxx

      • ソースURL: artc://domain/app/streamname?auth=xxx

  2. サーバは、SDP回答とともに応答を返す。

    ApsaraVideo Liveのサーバーがリクエストを検証した後、サーバーはSDP応答を生成し、ライブストリーミングノードに関する情報を含む応答をクライアントに返します。 応答パラメーターの詳細については、このトピックの「RTSシグナリングプロトコルの定義」をご参照ください。

  3. クライアントは、ICE (Interactive Connectivity Establishment) を開始します。

    1. クライアントがSDP回答を含む応答を受信した後、RTCPeerConnectionオブジェクトでセッション記述を指定します。

      peerConnection.setRemoteDescription(new RTCSessionDescription(answer.jsep));
    2. RTCPeerConnectionオブジェクトを使用して、ICEおよびデータグラムトランスポート層セキュリティ (DTLS) 暗号化を開始します。 シグナリングチャネルが確立されると、クライアントはApsaraVideo Liveからストリームをプルできます。 このようにして、WebRTCの標準に基づいてストリームのプルと再生を実装できます。

  4. クライアントが切断を開始します。

    クライアントは、ストリームの取り込みまたは再生を停止するために切断を開始するDTLS警告メッセージを送信します。

    Disconnect

HTML5プレーヤーのサンプルコード

// 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);


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

  peerConnection.setLocalDescription(offer_sdp).then(function() {
    // Get pull stream 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);
}
                                

RTSシグナリングプロトコルの定义

RTSシグナリングプロトコルは、HTTPSに基づいて短期間の接続を確立します。 プロトコルはJSON形式のメッセージを使用します。 サンプルコード:

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

Playback

  • 再生のプロトコル説明

    表 1. リクエストパラメーター

    パラメーター

    データ型

    必須

    説明

    モード

    String

    課金されます

    ストリームのモード。 この例では、パラメーターをliveに設定します。

    version

    int

    課金されます

    プロトコルのバージョン。 この例では、パラメーターを2に設定します。

    push_stream

    String

    課金されません

    取り込みURL。

    pull_streams

    []object

    課金されません

    プルするストリーム。The stream that you want to pull. 一度に複数のストリームをプルできます。 pull_streamパラメーターの属性の詳細については、次の表をご参照ください。

    sdk_version

    String

    課金されません

    SDKのバージョン。

    jsep. 型

    String

    課金されます

    SDPメッセージのタイプ。 この例では、パラメーターをofferに設定します。

    jsep.sdp

    String

    課金されます

    SDPメッセージの説明。

    表 2. pull_streamパラメーターの属性

    属性

    データ型

    必須

    説明

    url

    String

    課金されます

    artc:// で始まるソースURL。

    amsid

    []string

    課金されます

    プルするオーディオストリームのメディアストリームID (MSID) 。 この例では、パラメーターをrts audioに設定します。

    vmsid

    []string

    課金されます

    プルするビデオストリームのMSID。 この例では、パラメーターをrts videoに設定します。

    表 3. 応答パラメーター

    パラメーター

    データ型

    必須

    説明

    code

    int

    課金されます

    HTTP ステータスコード リクエストが成功した場合、コード200が返されます。 ステータスコードの詳細については、「ステータスコード」セクションを参照してください。

    trace_id

    String

    課金されます

    リクエストのグローバル一意ID (GUID) 。 GUIDはAlibaba Cloud CDNによって生成され、問題のトラブルシューティングに使用できます。 GUIDを正しく保持します。

    jsep. 型

    String

    課金されます

    SDPメッセージのタイプ。 この例では、値の答えが返されます。 .

    jsep.sdp

    String

    課金されます

    CDNノードがオリジンからストリームをプルするときに生成されるSDPメッセージの説明。

  • 再生リクエストの例

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

    sps-pps-idr-in-keyframe: ブラウザが悪いネットワーク条件下でライブストリームを再生するときに画面がちらつきないように、次の操作を実行することを推奨します。

    HTML5再生用にサブスクライブされたストリームのSDPオファーが作成された後、setLocalDescriptionを呼び出す前に、SDPメッセージを変更します。 H.264ビデオ属性について次のような行を検索します。

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

    sps-pps-idr-in-keyframe=1を追加します。 行は次のようになります。

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

    GRTNは応答し、ブラウザの機能をオンにします。

  • エラー処理

    ストリームプルリクエストが有効な場合、HTTPステータスコード200が返されます。 エラー処理の結果は、JSON形式のレスポンス本文で返されるHTTPステータスコードによって異なります。 次の表に、レスポンスのコードとメッセージのパラメーターを示します。

    Response:
    {
       "code": 200, // A value of 200 indicates that the request is successful. For more information about status codes, see the "Status codes" section.
       "message": "success" // The returned message.
    }

    表 4. 応答パラメーター

    パラメーター

    データ型

    説明

    code

    int

    HTTP ステータスコード 詳細については、「ステータスコード」セクションを参照してください。

    message

    String

    返されるメッセージ。

    表 5. ステータスコード

    ステータスコード

    説明

    403

    認証が失敗したことを示します。

    404

    ストリームが存在しないことを示します。

    611

    クライアントがTCP経由でストリームを再生する必要があることを示します。

    302

    クライアントが新しいアドレスに要求を送信する必要があることを示します。

アップストリーミング

  • ストリーム取り込みに関するプロトコルの説明

    表 6. リクエストパラメーター

    パラメーター

    データ型

    必須

    説明

    モード

    String

    課金されます

    ストリームのモード。 この例では、パラメーターをliveに設定します。

    version

    int

    課金されます

    プロトコルのバージョン。 この例では、パラメーターを2に設定します。

    push_stream

    String

    課金されません

    取り込みURL。

    sdk_version

    String

    課金されません

    SDKのバージョン。

    jsep. 型

    String

    課金されます

    SDPメッセージのタイプ。 この例では、パラメーターをofferに設定します。

    jsep.sdp

    String

    課金されます

    SDPメッセージの説明。

    表7. 応答パラメーター

    パラメーター

    データ型

    必須

    説明

    code

    int

    課金されます

    HTTP ステータスコード リクエストが成功した場合、コード200が返されます。 ステータスコードの詳細については、「ステータスコード」セクションを参照してください。

    trace_id

    String

    課金されます

    リクエストのGUID。 GUIDはAlibaba Cloud CDNによって生成され、問題のトラブルシューティングに使用できます。 GUIDを正しく保持します。

    jsep. 型

    String

    課金されます

    SDPメッセージのタイプ。 この例では、値の答えが返されます。

    jsep.sdp

    String

    課金されます

    CDNノードがオリジンからストリームをプルするときに生成されるSDPメッセージの説明。

  • ストリーム取り込みリクエストの例

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

    前述のシグナリング要求では、push_streamは取り込みURLを示します。これは、リアルタイムメッセージングプロトコル (RTMP) を介したストリーム取り込みに似ています。 以下の点に注意する必要があります。

    • SDPメッセージでMSIDを指定する必要があります。 GRTNは、メディアストリームを識別するためにMSIDを使用します。

    • メディアストリームはネゴシエーションをサポートしていません。 クライアントによって指定されたMSIDの場合、1つのコーデックのみが許可されます。 GRTNは選択を行いません。 サポートされているコーデックには、Advanced Audio Coding (AAC) 、Opus、H.264、およびH.265が含まれます。

    • オーディオのサンプルコードaudio1audio2

    • ビデオ video1video2

  • エラー処理

    ストリームプルリクエストが有効な場合、HTTPステータスコード200が返されます。 エラー処理の結果は、JSON形式のレスポンス本文で返されるHTTPステータスコードによって異なります。 次の表に、レスポンスのコードとメッセージのパラメーターを示します。

    Response:
    {
       "code": 200, // A value of 200 indicates that the request is successful. For more information about status codes, see the "Status codes" section.
       "message": "success" // The returned message.
    }

    表8. 応答パラメーター

    パラメーター

    データ型

    説明

    code

    int

    HTTP ステータスコード 詳細については、「ステータスコード」セクションを参照してください。

    message

    String

    返されるメッセージ。

    表9. ステータスコード

    ステータスコード

    説明

    403

    認証が失敗したことを示します。

    611

    クライアントがTCP経由でストリームを再生する必要があることを示します。

    302

    クライアントが新しいアドレスに要求を送信する必要があることを示します。

SDPネゴシエーションの強化

メッセージは、シグナリング中にSDPフォーマットで交換される。 SDPネゴシエーションは、一般に、RFC 4566に基づく。 RTSは、ネゴシエーションをライブストリーミング業界の特性と互換性のあるものにするために、より多くのセマンティクスを拡張します。 RTSは、ビデオとオーディオのより多くのコンテナ形式と、より多くの通信プロトコルをサポートします。 このように、RTSは、WebRTCがオーディオのOpus形式のみをサポートし、Bフレームをサポートしないという問題を解決します。 RTSは、増加するストリーミングプロトコルのニーズを満たします。

ストリームの取り込みと引きのためにサポートされているAAC

RTSは、RTMPを介してさまざまなAAC形式でオーディオを送信できます。 AACフォーマットは、AAC-LC、HE-AACv1、およびHE-AACv2を含みます。

RTSは、低オーバーヘッドMPEG-4オーディオトランスポート多重 (LATM) コンテナフォーマットを使用して、AACフォーマットでオーディオを送信できます。 LATMは、オーディオが符号化情報を含むかどうかに基づいて、オーディオに関する符号化情報が帯域内モードで送信されるか帯域外モードで送信されるかを決定します。 帯域内伝送は、各オーディオフレームの符号化情報を送信する。 帯域外伝送は、符号化情報を一度だけ送信します。 AudioMuxElement配列内のmuxconfigPresentパラメータは、AudioSpecificConfig内の情報が帯域内モードで送信されるか帯域外モードで送信されるかを指定します。 したがって、LATMは、オーディオデータ転送ストリーム (ADTS) よりも柔軟です。 AudioSpecificConfig内の情報が変更されないままである場合、StreamMuxConfig内の情報は、SDPメッセージで最初に送信されます。

  • AACはストリーム取り込みに対応

    SDPオファーに関連情報を掲載することで、AACオーディオ形式をサーバーに通知できます。 また、fmtp属性には、取り込んだストリームのAudioSpecificConfigから取得したconfig=StreamMuxConfigを追加できます。 このようにして、AudioSpecificConfigパラメータをサーバに搬送して、AACヘッダを生成することができます。

    SDPオファー

    a=rtpmap:125 MP4A-LATM/48000/2
    a=fmtp:125 config=4000232000;cpresent=0;object=2;profile-level-id=1 
  • AACサポート用ストリーム引き

    シグナリング中、RTSはオーディオストリームの取り込み中にエンコード情報を解析し、次のコードに示すように、ネゴシエーション応答で解析された情報を返します。

    SDPオファー

    SDP回答

    AAC-LC

    HE-AACv1

    HE-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

    MP4A-LATMのfmtp属性にSBR-enabled=1が追加された場合、AACフォーマットがAAC-HEされます。 SBR-enabled=1PS-enabled=1が追加された場合、AACフォーマットがHE-AACv2されます。 AAC形式は、AAC-LCからHE-AACv2に進化しています。 したがって、fmtp属性においてSBRおよびPSフィールドを使用して、AACフォーマットを示すことができる。 さらに、fmtp属性にconfig=StreamMuxConfigを追加できます。 StreamMuxConfigは、取り込まれたストリームのAudioSpecificConfigから取得され、符号化情報の詳細に関連するパラメータを含む。 クライアントは必要に応じて詳細を取得できます。

    002

ストリームの取り込みと引きのためにサポートされるH.265

  • H.265のストリーム取り込み

    SDPオファーに関連情報を掲載することで、H.265ビデオフォーマットをサーバーに通知できます。

    SDPオファー:

    a=rtpmap:102 H265/90000 
  • H.265はストリームプル

    ストリームプリングのシグナリングプロセス中に、サーバは、H.264、H.265などのソースストリームのビデオコーデックを取得し、その情報に基づいてネゴシエーションを実行します。

    SDPオファー

    SDP回答

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

ストリームの取り込みとプルでサポートされるBフレーム

  • ストリーム取り込みでサポートされるBフレーム

    Bフレームは、取り込まれたストリームでサポートされます。

  • ストリームプルでサポートされるBフレーム

    シグナリング中、クライアントは、Bフレームを含むビデオを復号するかどうかを指定するために、SDPオファーにフィールドを追加することができます。 たとえば、クライアントがfmtp属性にBFrame-enabled = 1を追加した場合、クライアントはBフレームを含むビデオをデコードできます。 この場合、RTP timestamp = PTSを追加することができ、これは、クライアントが、増加するシーケンス番号に基づいて各フレームを復号することを意味します。 Bフレームを含むビデオがサポートされていない場合、RTSはソースストリームをトランスコードしてBフレームを削除できます。

    Bフレームを含むビデオをデコードするために、「RTP timestamp = PTS」を追加することができます。 クライアントは、増加するシーケンス番号に基づいて各フレームを復号します。

    さらに、サーバは、構成タイムスタンプ (CTS) を返すことができます。 これにより、クライアントは、以下の式に基づいて復号タイムスタンプ (DTS) を計算することができます。 SDPオファーがa=extmap:{$id} uri:webrtc:rtp-hdrext:video:CompositionTimeを含む場合、RTSは拡張識別子= {$id} を各ビデオフレームの最初のリアルタイムトランスポートプロトコル (RTP) パケットに追加します。 id変数の値は、クライアントによって送信されるSDPオファーによって決定されます。

    RTSにより、クライアントは、Bフレームを含むビデオをデコードするかどうか、およびCTS情報を返すかどうかを判断できます。 RTSは、通信における一般的な方法を最初から値にします。

次の図は、ストリームプル中のSDPオファーとパケットキャプチャの部分的なコンテンツを示しています。

Partial content of the SDP offer004

ストリーム取り込みでサポートされるメタデータを運ぶシグナリング要求

RTMPを介して取り込まれたストリームはメタデータを保持します。メタデータは、コールバックを返し、ストリームプルクライアントの情報を提供するために使用できます。 しかしながら、WebRTCシグナリングプロセスは、メタデータを含まない。 改善策として、RTSは、メタデータがシグナリング要求において搬送されることを可能にします。 このようにして、取り込まれたストリームでメタデータを生成できます。

取り込まれたストリームのシグナリング要求の本文にメタデータフィールドを追加します。

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

MSIDメカニズム

MSIDの詳細については、「Msidメカニズム」をご参照ください。 次の内容に注意してください。Msid